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Abstract 


Dynamic  distributed  systems,  where  a  changing  set  of  communicating  processes  must  inter¬ 
operate  to  accomplish  particular  computational  tasks,  are  becoming  extremely  important.  De¬ 
signing  and  implementing  these  systems,  and  verifying  the  correctness  of  the  designs  and 
implementations,  are  difficult  tasks.  The  goal  of  this  thesis  is  to  make  these  tasks  easier. 

This  thesis  presents  a  specification  language  for  dynamic  distributed  systems,  based  on 
Chandy  and  Misra’s  UNITY  language.  It  extends  the  UNITY  language  to  enable  process  creation, 
process  deletion,  and  dynamic  communication  patterns. 

The  thesis  defines  an  execution  model  for  systems  specified  in  this  language,  which  leads  to 
a  proof  logic  similar  to  that  of  UNITY.  While  extending  UNITY  logic  to  correctly  handle  systems 
with  dynamic  behavior,  this  logic  retains  the  familiar  UNITY  operators  and  most  of  the  proof 
rules  associated  with  them. 

The  thesis  presents  specifications  for  three  example  dynamic  distributed  systems  to  demon¬ 
strate  the  use  of  the  specification  language,  and  full  correctness  proofs  for  two  of  these  systems 
and  a  partial  correctness  proof  for  the  third  to  demonstrate  the  use  of  the  proof  logic. 

The  thesis  details  a  method  for  determining  whether  a  system  in  the  specification  language 
can  be  transformed  into  an  implementation  in  a  standard  programming  language,  as  well  as  a 
method  for  performing  this  transformation  on  those  specifications  that  can.  This  guarantees 
a  correct  implementation  for  any  specification  that  can  be  so  transformed. 
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Chapter  1 

Introduction 


1.1  Motivation 

A  distributed  system  is  a  system  that  consists  of  multiple  communicating  processes.  A  dynamic 
distributed  system  has  the  additional  characteristic  that  the  processes  that  make  up  the  system 
can  enter  and  leave  the  system  while  the  system  is  running.  Dynamic  distributed  systems  have 
become  increasingly  important  in  recent  years,  as  more  computers  have  been  attached  to  the 
Internet  on  a  part-time  or  full-time  basis.  Most  of  the  core  services  on  the  Internet  that  are 
used  by  millions  of  people  daily,  including  the  Domain  Name  System  (DNS)  [50,  51]  and  the 
Simple  Mail  Transport  Protocol  (SMTP)  [59],  are  implemented  as  large-scale  dynamic  distributed 
systems,  though  most  users  never  see  them  as  such.  Popular  Internet-based  computing  projects 
such  as  SETIAHome  [65],  which  analyzes  signals  in  an  attempt  to  detect  interstellar  life,  and 
distributed.net  [18],  which  performs  various  computations  including  brute-force  encryption 
cracking  and  searching  for  optimal  Golomb  rulers,  are  also  examples  of  dynamic  distributed 
systems.  These  projects  allow  individual  users  to  participate  in  huge  distributed  computations 
simply  by  running  screen  savers  or  other  client  programs  on  their  Internet-connected  home 
computers;  when  a  particular  computer  is  connected  to  the  network  it  communicates  with  the 
servers  that  coordinate  the  distributed  system,  and  when  it  is  disconnected  from  the  network 
it  continues  its  computational  tasks  in  isolation. 

Both  theory  and  experience  have  shown  that  designing  correct  distributed  systems  (that  is, 
distributed  systems  that  can  be  proven  to  successfully  perform  the  tasks  they  are  designed  for) 
is  substantially  more  difficult  than  designing  correct  non-distributed  ones.  The  addition  of  dy¬ 
namic  behavior  makes  designing  correct  systems  even  more  difficult.  While  many  specification 
and  proof  methods  for  distributed  systems  have  been  proposed  and  used  to  varying  degrees 
of  effectiveness,  the  same  is  not  true  of  dynamic  distributed  systems.  There  is  a  notable  lack 
of  specification  and  proof  techniques  for  such  systems,  despite  the  fact  that  they  are  becoming 


more  common. 


2 


program  division 


declare 

x,  y,  z,  k:  integer 
initially 

x,  y,  z,  k  :=  0,  M,  N,  1 


assign 

z,  k  :=  2  x  z,  2  x  k 
N  ,  1 

0  x,  y:=x  +  k,  y-z 


if  y  >  2  x  z  ~ 
if  y  <  2  x  z 
if  y  >  z 


end 


Specification  1.1:  A  UNITY  program  that  implements  integer  division 


The  goal  of  this  work  is  to  facilitate  the  construction  of  correct  dynamic  distributed  systems, 
by  providing  a  specification  language  and  proof  logic  that  extends  established  specification  and 
proof  techniques  for  distributed  systems  into  the  dynamic  world.  In  particular,  we  modify  the 
UNITY  formalism,  which  was  introduced  by  Chandy  and  Misra  [8]  for  the  specification  and  proof 
of  parallel  and  distributed  programs,  to  create  a  new  formalism  called  Dynamic  UNITY  that 
can  be  used  to  specify  and  reason  about  dynamic  distributed  systems.  We  present  examples 
that  illustrate  the  utility  of  Dynamic  UNITY,  and  also  show  how  Dynamic  UNITY  specifications 
can  be  implemented  as  real  distributed  systems  in  mainstream  programming  languages  like 
Java. 

1.2  The  UNITY  Formalism 

The  UNITY  formalism  allows  for  reasoning  about  concurrent  programs  in  a  straightforward 
fashion.  A  UNITY  program  is  a  set  of  variables,  a  set  of  initialization  statements,  and  a  set  of 
multiple  assignment  statements.  An  example  of  a  UNITY  program  is  Specification  1.1,  which 
divides  the  integer  M  by  the  integer  N  and  stores  the  quotient  in  x  and  the  remainder  in  y.1 

The  execution  of  a  UNITY  program  proceeds  in  the  following  way:  First,  the  assignments  in 
the  initially  section  (if  any)  are  executed.  This  sets  the  state  variables  of  the  program  to  their 
initial  values.  Then,  assignments  from  the  assign  section  are  repeatedly  chosen  and  executed 
according  to  a  weak  fairness  constraint.  In  UNITY,  the  weak  fairness  constraint  ensures  that 
in  an  infinite  execution  of  a  program,  every  assignment  statement  in  the  program  is  executed 

1This  program  is  proven  to  be  correct— that  is,  it  is  shown  that  the  state  variables  x  and  y  eventually  hold  the 
quotient  and  the  remainder  that  result  from  dividing  M  by  N— by  Chandy  and  Misra  [8],  as  the  first  complete  example 
of  a  UNITY  program  with  a  corresponding  proof. 
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infinitely  often.  When  an  assignment  statement  is  executed,  its  guard  (if  any)  is  evaluated,  and 
if  it  evaluates  to  true,  the  state  variables  change  according  to  the  assignment  statement.  In 
the  case  of  a  conditional  assignment  statement,  as  in  the  program  above,  all  the  guards  are 
evaluated  simultaneously,  and  the  state  variables  change  according  to  the  assignment  (if  any) 
whose  guard  evaluates  to  true.  Each  assignment  statement  is  executed  atomically,  so  there  is 
no  interference  among  assignment  statements  that  modify  the  same  state  variable. 

This  simple  execution  model  is  what  makes  UNITY  a  powerful  formalism.  UNITY  has  no 
sequencing  operator,  and  makes  no  guarantees  about  the  order  in  which  assignments  are  exe¬ 
cuted  other  than  the  weak  fairness  guarantee;  the  execution  order  of  program  statements  need 
not  be  considered  explicitly  while  constructing  proofs  of  UNITY  programs.  Additionally,  the 
semantics  of  the  multiple  assignment  operation  are  well-understood,  which  means  that  the  be¬ 
havior  of  UNITY  programs — that  by  definition  consist  entirely  of  atomic  multiple  assignment 
operations— is  straightforward  to  analyze. 

However,  UNITY’S  simplicity  makes  it  inconvenient  for  use  in  specifying  dynamic  systems. 
Specifically,  UNITY  programs  have  static  sets  of  state  variables  and  static  sets  of  assignments, 
which  means  that  they  can  describe  systems  with  dynamic  behavior  only  with  great  difficulty, 
by  explicitly  providing  assignments  for  every  possible  instance  of  the  dynamic  behavior.  In 
addition,  UNITY  programs  are  difficult  to  compose  into  multiple-program  systems,  in  part  be¬ 
cause  there  are  no  primitive  communication  operations  aside  from  the  multiple  assignment 
statement.  While  it  is  certainly  possible  to  build  a  UNITY  system  composed  of  multiple  UNITY 
programs  and  take  advantage  of  proof  reuse,  it  is  extremely  difficult,  as  illustrated  in  Charpen- 
tier  and  Chandy  [11],  The  correctness  of  the  program  in  Specification  1.1  can  easily  be  proven 
in  isolation,  but  every  time  it  is  composed  with  another  UNITY  program  additional  proof  steps 
must  be  carried  out  to  ensure  that  no  adverse  effects  arise  from  the  composition. 

1.3  Dynamic  UNITY 

Dynamic  UNITY  extends  the  UNITY  formalism  by  adding  the  concept  of  processes,  new  primi¬ 
tives  for  the  creation  and  destruction  of  processes,  and  new  primitives  and  a  reliable  messaging 
layer  for  interprocess  communication.  It  also  changes  the  program  notation  to  one  based  on 
binary  predicates  instead  of  on  assignment  statements,  similar  to  the  notation  of  Hehner  [23] 
and  of  Lamport’s  Temporal  Logic  of  Actions  [35],  and  eliminates  the  sharing  of  variables  among 
multiple  programs.  These  extensions  and  changes,  which  will  be  discussed  in  more  detail  later, 
make  it  easier  to  specify  and  prove  the  correctness  of  dynamic  distributed  systems. 

As  an  example,  Specification  1.2  is  a  Dynamic  UNITY  program  that  implements  exactly  the 
same  algorithm  as  Specification  1.1.  The  correctness  of  this  program  is  proven  in  a  manner  sim- 


4 


program  DivisionModule(M:  integer,  N:  integer,  proc:  process,  mbox:  string) 
declare 

x,  y,  z,  k:  integer 
initially 

x=OAy=MAz=NAk=l 

fair-transition 

y  >  2  x  z  — >  z'  =  2  x  z  A  k'  =  2xz 
0  y<2xz  — >  z'  =  N  A  k'  =  1 
Q  y  >  z  — >x'=x  +  kAy'  =  y-  z 

0  xxN  +  y  =  MAO<y<N  — *  send(proc,  mbox,  x,  proc,  mbox,  y)  a  stop 


end 


Specification  1.2:  A  Dynamic  UNITY  program  that  implements  integer  division 


ilar  to  that  used  for  proving  the  UNITY  program.  However,  while  the  UNITY  program  cannot  be 
easily  integrated  into  a  larger  system,  the  Dynamic  UNITY  program  has  well-defined  semantics 
for  such  integration:  when  the  division  is  complete  it  will  send  first  the  quotient  and  then  the 
remainder  as  messages  to  the  inbox  of  process  proc  whose  name  is  contained  in  mbox,  and  will 
also  stop  its  own  execution  (removing  itself  from  the  system)2.  Thus,  in  any  situation  where  a 
division  needs  to  be  carried  out  and  the  quotient  and  remainder  need  to  be  sent  to  a  particular 
place  in  the  system,  an  instance  of  DivisionModule  can  be  created  with  the  proper  parameters. 
This  particular  example  would  never  be  used  in  a  real  system,  as  division  is  typically  available 
as  a  primitive  operation;  however,  the  principle  applies  to  far  more  complicated  programs  as 
well. 

By  extending  the  UNITY  formalism,  we  are  able  to  take  advantage  of  the  experience  accumu¬ 
lated  by  UNITY  practitioners.  Much  of  the  high-level  logical  framework  of  Dynamic  UNITY  is 
essentially  identical  to  that  of  UNITY,  though  Dynamic  UNITY’S  underlying  execution  model  dif¬ 
fers  significantly  from  UNITY’S  execution  model.  Furthermore,  Dynamic  UNITY’S  proof  logic  is 
based  on  a  small  set  of  fundamental  concepts:  invariants,  variant  functions,  and  leads-to  and 
follows  properties.  This  facilitates  both  formal  reasoning  and  informal  analysis  of  Dynamic 
UNITY  specifications. 

1.4  Contributions 

The  contributions  of  this  thesis  are  as  follows: 

2The  guard  for  the  transition  which  performs  the  message  send  and  stops  the  process  is  exactly  the  predicate 
which  holds  at  all  fixed  points  of  the  original  UNITY  program. 
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1.  A  specification  language  for  dynamic  distributed  systems. 

2.  A  proof  logic  for  dynamic  distributed  systems. 

3.  A  method  for  transforming  systems  from  our  specification  language  into  an  implementa¬ 
tion  language,  so  they  can  be  run  on  actual  distributed  systems. 

1.5  Thesis  Structure 

The  remainder  of  this  thesis  is  structured  as  follows: 

In  Chapter  2,  we  introduce  the  Dynamic  UNITY  formalism.  We  discuss  in  some  detail  the 
differences  between  UNITY  and  Dynamic  UNITY  and  describe  the  syntax  of  the  Dynamic  UNITY 
language.  We  also  give  a  brief  overview  of  the  execution  semantics  of  Dynamic  UNITY  systems, 
including  an  informal  definition  of  the  message-passing  layer  through  which  Dynamic  UNITY 
processes  communicate. 

In  Chapter  3,  we  rigorously  define  the  execution  model  for  Dynamic  UNITY  systems  and  the 
Dynamic  UNITY  message-passing  layer,  and  introduce  a  logic  for  the  verification  of  Dynamic 
UNITY  specifications.  We  adapt  the  temporal  operators  commonly  used  in  proving  the  correct¬ 
ness  of  UNITY  programs  for  use  in  proving  the  correctness  of  Dynamic  UNITY  specifications. 

In  Chapters  4  and  5,  we  present  two  example  Dynamic  UNITY  systems— a  prime  number 
sieve,  which  results  in  the  creation  of  an  infinite  number  of  communicating  processes,  and  a 
dynamic  single  resource  mutual  exclusion  system,  where  consumers  of  the  single  resource  can 
enter  and  leave  the  system  at  any  time  during  their  execution.  We  also  carry  out  complete 
proofs  of  correctness  for  these  systems. 

In  Chapter  6,  we  present  an  example  Dynamic  UNITY  system  that  implements  a  solution 
to  a  dynamic  version  of  the  drinking  philosophers  problem.  We  also  carry  out  a  partial  proof 
of  progress  for  our  solution.  The  safety  properties  of  this  solution  are  straightforward  and 
similar  to  those  of  the  single  resource  mutual  exclusion  system. 

In  Chapter  7,  we  discuss  techniques  for  the  implementation  of  Dynamic  UNITY  specifica¬ 
tions  on  actual  computer  systems.  As  an  example  of  one  such  implementation  technique,  we 
formulate  a  method  for  the  direct  translation  of  many  Dynamic  UNITY  specifications  into  Java 
code. 

In  Chapter  8,  we  outline  some  related  work  and  compare  our  research  to  other  specification 
and  proof  methods  for  distributed  systems. 

In  Chapter  9,  we  present  a  summary  of  our  results  and  a  discussion  of  the  applicability  of 
these  results.  We  also  discuss  potential  future  research  directions. 
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Chapter  2 

Dynamic  UNITY 


In  this  chapter,  we  introduce  the  Dynamic  UNITY  formalism,  which  allows  us  to  reason  about 
algorithms  and  protocols  in  which  the  sets  of  participating  processes  change  over  time.  By  ex¬ 
tending  the  familiar  UNITY  formalism,  we  are  able  to  take  advantage  of  many  UNITY  proof  rules 
and  techniques  while  reasoning  about  dynamic  systems  that  cannot  be  adequately  described 
using  UNITY. 

We  first  detail  the  changes  and  extensions  to  the  original  UNITY  formalism  that  allow  Dy¬ 
namic  UNITY  to  encompass  dynamic  systems;  then,  we  introduce  the  Dynamic  UNITY  notation 
and  briefly  discuss  the  execution  semantics  of  Dynamic  UNITY  systems. 

2.1  Extending  UNITY  to  Dynamic  Systems 

We  have  previously  given  an  overview  of  the  UNITY  formalism,  including  a  brief  description 
of  its  execution  model.  Changes  to  the  execution  model,  as  well  as  to  the  proof  logic  and  the 
specification  language  itself,  are  necessary  to  adapt  UNITY  to  handle  systems  where  processes 
can  be  created  and  destroyed  at  runtime.  In  order  to  make  this  task  more  manageable,  we 
restrict  our  attention  to  systems  that  satisfy  the  following  constraints: 

1.  Each  process  has  access  only  to  its  own  state— that  is,  there  is  no  direct  sharing  of  variables 
among  the  processes. 

2.  Processes  communicate  only  via  asynchronous  message  passing. 

3.  Any  process  can  create  new  processes,  and  any  process  can  destroy  itself,  but  no  process 
can  destroy  other  processes. 


These  constraints  are  not  chosen  arbitrarily — each  helps  to  make  the  tasks  of  designing 
and  proving  the  correctness  of  a  dynamic  distributed  system  easier.  The  first  eliminates  any 
possibility  that  processes  can  directly  interfere  with  each  others’  operation,  allowing  for  both 
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modular  reasoning  (proof  reuse)  and  modular  system  construction;  the  second  restricts  in¬ 
terprocess  communication  to  a  single  well-understood  mechanism,  which  simplifies  system 
design;  and  the  third  simplifies  proof  obligations  by  eliminating  the  possibility  that  a  running 
process  will  be  destroyed  at  an  unexpected  or  inappropriate  time. 

Each  constraint  is  enforced  by  specific  changes  to  the  UNITY  formalism.  We  eliminate  the 
notion  of  shared  variables  entirely,  since  we  are  only  considering  systems  with  no  shared  state. 
We  add  reliable  first-in  first-out  message  passing  as  a  primitive  of  the  language  and  create  new 
operations  to  manipulate  messages  in  various  ways.  We  also  add  the  notion  of  programs  and 
processes  by  changing  the  formalism  in  a  fundamental  way— instead  of  a  single  program,  a 
Dynamic  UNITY  system  consists  of  multiple  programs  that  are  instantiated  as  processes  and 
that  can  halt  their  own  execution.  We  can  then  prove  properties  about  individual  programs 
independent  of  the  behavior  of  other  programs  in  the  system. 

In  addition  to  these  changes,  we  also  change  the  notation  for  Dynamic  UNITY  specifications: 
instead  of  guarded  parallel  assignment  statements,  we  use  guarded  binary  predicates  to  rep¬ 
resent  state  transitions.  This  change  provides  more  flexibility  for  program  designers,  enabling 
them  to  focus  directly  on  the  result  of  each  transition  rather  than  on  the  precise  set  of  assign¬ 
ment  statements  needed  to  make  that  result  happen.  However,  it  also  makes  it  much  easier  to 
create  Dynamic  UNITY  specifications  that  are  not  implementable  on  actual  computer  systems, 
a  topic  we  will  discuss  further  in  Chapter  7. 

2.2  Dynamic  UNITY  Notation 

We  describe  the  notation  of  Dynamic  UNITY  using  BNF.  Nonterminal  symbols  are  italicized, 
and  terminal  symbols  are  in  plain  or  boldface  type.  “(X)*”  denotes  a  syntactic  unit  X  that  may 
be  instantiated  zero  or  more  times,  “(X)+”  denotes  a  syntactic  unit  X  that  may  be  instantiated 
one  or  more  times,  “(X)1”  denotes  a  syntactic  unit  X  that  may  be  instantiated  one  time  or  not 
instantiated  at  all. 

During  the  notation  description,  we  enumerate  certain  conditions  under  which  particular 
constructs  are  considered  malformed.  A  Dynamic  UNITY  system  with  malformed  constructs 
can  be  syntactically  legal,  but  we  make  no  guarantees  about  the  behavior  of  systems  with 
malformed  constructs.  A  system  that  contains  no  malformed  constructs  is  considered  well- 
formed;  a  proof  of  well-formedness  is  one  of  the  obligations  for  any  correctness  proof  of  a 
Dynamic  UNITY  system. 
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2.2.1  Program  Structure 

program-section  > — »  (program  |  initial-program)  program-name  ((parameter-list))1 

(type  type-section)1 
(declare  declare-section)1 
(always  always-section)1 
(initially  initially-section) 1 
(fair-transition  transition-section)1 
(unfair-transition  transition-section) 1 
end 

parameter-list  > — *  parameter-name :  external-type-name 

(,  parameter-name:  external-type-name)* 

A  program  can  start  with  either  the  keyword  program  or  the  keyword  initial-program.  The 
latter  indicates  that  the  program  will  be  the  first  one  instantiated  when  system  execution  begins. 
A  system’s  initial  program  is  usually  a  setup  program  that  instantiates  one  or  more  other 
programs  to  bootstrap  the  system.  There  is  always  exactly  one  initial  program  in  a  well-formed 
system. 

A  program-name  is  any  string  of  letters  and  digits,  with  the  restriction  that  no  two  programs 
in  the  same  system  may  have  identical  names.  A  parameter-name  is  any  string  of  letters  and 
digits,  with  the  restrictions  that  no  two  parameters  declared  in  a  program  may  have  identical 
names  and  that  no  parameter  declared  in  a  program  may  have  the  same  name  as  a  variable  or 
definition  declared  in  that  program.  An  external-type-name  is  a  primitive  data  type  (such  as 
integer  or  set),  the  name  of  a  data  type  declared  in  the  type-section  (described  in  Section  2.2.2) 
of  the  system,  or  the  name  of  another  program  declared  in  the  system. 

The  program  execution  starts  in  a  state  where  the  set  of  parameters  is  as  specified  at  process 
instantiation  (described  in  Section  2.2.8. 1),  the  set  of  variables  is  as  declared  in  the  declare- 
section  (described  in  Section  2.2.3),  the  set  of  definitions  is  as  declared  in  the  always-section 
(described  in  Section  2.2.4),  and  the  initial  states  of  all  variables  are  as  specified  in  the  ini  daily- 
section  (described  in  Section  2.2.5). 

The  current  definition  of  Dynamic  UNITY  does  not  allow  for  hierarchical  program  structure. 
We  discuss  the  possibility  of  adding  this  capability  to  Dynamic  UNITY  in  Chapter  9. 

2.2.2  Type  Section 

type-section  > — »  (declared-type-name:  type-specifier )+ 
type-specifier  > — ►  array-type  \  primitive-type  \  record-type  \  sequence-type  \  set-type 
array-type  > — »  arrayd™  {type-name  \  type-specifier} 
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primitive-type 

record-type 


sequence-type 

set-type 


any  |  boolean  |  inbox  |  integer  |  process  |  real  |  string 
record  { field-name :  ( type-name  \  type-specifier) 

(,  field-name :  ( type-name  \  type-specifier))*} 
sequence  {type-name  \  type-specifier} 

(multiset  |  set)  {type-name  \  type-specifier} 


A  declared-type-name  is  any  string  of  letters  and  digits,  with  the  restrictions  that  no  two 
types  declared  in  the  same  program  may  have  identical  names  and  that  no  type  declared  in  a 
program  may  have  the  same  name  as  a  primitive  type,  a  type  declared  in  the  system  containing 
that  program,  or  a  variable  declared  in  that  program.  A  type-name  is  a  primitive  data  type, 
the  name  of  a  data  type  declared  in  the  program’s  type-section  or  the  system’s  type-section,  or 
the  name  of  another  program  declared  in  the  system.  A  field-name  is  any  string  of  letters  and 
digits,  with  the  restrictions  that  no  two  fields  declared  in  the  same  type  may  have  the  same 
name  and  that  no  held  may  be  named  “type”  (type  is  a  Dynamic  UNITY  operation  that  allows  a 
process  to  determine  the  type  of  an  object  it  receives  through  message  passing;  it  is  described 
in  Section  2. 2. 8.4).  The  dim  superscript  used  with  array  is  a  positive  integer  that  determines  the 
array’s  dimensionality.  The  any  type  allows  for  the  construction  of  sets,  arrays,  and  sequences 
that  can  contain  elements  of  any  primitive  or  declared  type. 

Dynamic  UNITY’S  primitive  types  support  the  expected  range  of  operations:  individual  el¬ 
ements  of  arrays  and  sequences  can  be  accessed  using  “[]”  syntax,  fields  of  records  can  be 
accessed  using  syntax,  and  sets  and  multisets  can  be  used  with  the  operators  normally 
associated  with  mathematical  sets.  In  addition,  a  binary  concatenation  operator  (M)  generates 
sequences  from  other  sequences  or  elements. 

Some  of  Dynamic  UNITY’S  primitive  types  have  “special”  values:  the  empty  set  is  denoted 
by  0,  the  empty  sequence  is  denoted  by  A,  and  the  null  process,  a  value  given  to  a  process 
reference  to  indicate  that  it  does  not  point  to  a  process,  is  denoted  by  _L. 

Dynamic  UNITY’S  declared  types  are  not  types  in  the  sense  of  type  theory.  Instead,  they  are 
tags  that  exist  mainly  for  structuring  and  to  facilitate  message-based  communication.  They  are 
most  commonly  used  to  distinguish  between  multiple  message  types  that  may  be  received  by  a 
given  process  when  the  reaction  of  the  process  is  dependent  on  the  type  of  a  received  message. 

Example  2.1  (Type  declarations) 

1.  A  user  record  containing  a  username,  a  password,  and  a  unique  identification  number: 

UserRecord:  record  {name:  string,  password:  string,  UID:  integer} 

2.  A  set  of  user  records: 

UserRecordSet:  set  {UserRecord} 
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2.2.3  Declare  Section 

declare-section  > — »  (variable-name  (,  variable-name)* :  type-name)+ 

A  variable-name  is  any  string  of  letters  and  digits,  with  the  restrictions  that  no  two  variables 
declared  in  a  program  may  have  identical  names,  that  no  variable  declared  in  a  program  may 
have  the  same  name  as  a  parameter  or  definition  declared  in  that  program,  and  that  no  variable 
may  have  the  same  name  as  a  type  declared  in  the  type-sections  of  its  program  or  the  system. 
A  type-name  is  as  described  in  Section  2.2.2. 

The  declare-section  contains  the  variables  whose  values  can  be  changed  by  the  program  dur¬ 
ing  execution.  Initial  values  for  these  variables  are  specified  in  the  initially-section  (described 
in  Section  2.2.5).  Any  variable  for  which  an  initial  value  is  not  specified  in  the  initially-section  is 
implicitly  initialized  to  a  canonical  default  value  for  its  specified  type,  as  follows:  anys  are  ini¬ 
tialized  to  the  empty  set,  arrays  (of  unspecified  length),  sequences  and  sets  are  initially  empty, 
processes  are  initialized  to  the  empty  process,  booleans  are  initialized  to  false,  integers  and 
reals  are  initialized  to  0,  and  strings  are  initialized  to  the  empty  string.  Inboxes  are  implicitly 
assigned  names  equivalent  to  their  variable  names  (so  an  inbox  declared  as  “mylnbox:  inbox” 
would  be  named  “mylnbox”).  Implicit  initialization  is  recursive;  for  instance,  all  the  elements 
of  an  array  of  integers  with  specified  length  are  initialized  to  0.  Note  that  it  is  not  possible  to 
change  the  name  of  an  inbox  once  it  has  been  initialized,  so  any  inboxes  which  need  to  have 
names  other  than  their  variable  names  must  have  these  names  specified  in  the  initially-section. 

Variable  names  may  appear  primed  (myVariable')  in  the  transition-section  (described  in 
Section  2.2.6),  but  may  not  appear  primed  anywhere  else  in  a  program.  As  in  the  notation  of 
Hehner  [23]  and  in  Lamport’s  Temporal  Logic  of  Actions  [35],  primed  variable  names  represent 
the  variables  after  a  state  transition,  while  unprimed  variable  names  represent  the  variables 
before  a  state  transition.  Primed  and  unprimed  variable  names  can  be  used  together  to  specify 
binary  predicates  on  the  program  variables. 

Example  2.2  (Variable  declarations) 

1.  Two  sets  of  user  records  (explicit): 

privilegedUsers,  unprivilegedUsers:  set  {UserRecord} 

2.  Two  sets  of  user  records  (using  the  type  defined  in  Example  2.1): 
privilegedUsers,  unprivilegedUsers:  UserRecordSet 

3.  A  sequence  where  the  elements  can  be  of  any  type: 
unrestrictedSequence:  sequence  {any} 
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4.  An  array  of  sequences  of  integers: 

sequencesOflntegers:  array  {sequence  {integer}} 

2.2.4  Always  Section 

always-section  > — »  definition-name  =  expression 

(;  definition-name  =  expression)* 

A  definition-name  is  any  string  of  letters  and  digits,  with  the  restrictions  that  no  two  def¬ 
initions  declared  in  a  program  may  have  identical  names  and  that  no  definition  declared  in  a 
program  may  have  the  same  name  as  a  parameter  or  a  variable  declared  in  that  program.  An 
expression  is  an  arithmetic  or  logical  expression  in  one  or  more  of  the  variables,  parameters  and 
definitions  declared  in  the  program,  and  may  also  contain  certain  Dynamic  UNITY  operations 
(described  in  Section  2.2.8).  It  may  not  contain  primed  variables. 

The  always-section  is  used  to  create  definitions,  which  are  functions  of  program  variables 
and  parameters.  Definition  types  are  implicitly  specified  by  the  expressions  associated  with 
them.  A  definition  may  be  used  in  subsequent  definitions,  initialization  expressions,  and  tran¬ 
sition  expressions.  Every  appearance  of  a  definition  can  be  considered  a  “macro”  for  the  ex¬ 
pression  associated  with  it.  Definitions  are  considered  to  be  defined  in  the  order  in  which 
they  appear  (the  use  of  a  semicolon  as  the  separator  for  definitions  reinforces  this  notion  of 
sequencing).  An  always-section  that  contains  cyclical  definitions  is  considered  malformed. 

The  value  of  a  definition  may  not  be  changed  as  part  of  an  initialization  expression  (see 
Section  2.2.5)  or  transition  expression  (see  Section  2.2.6). 

Example  2.3  (Well-formed  always-sections) 

1.  A  Boolean  flag  that  is  true  if  and  only  if  the  privileged  user  set  is  empty: 

privilegedUsersIsEmpty  =  |privilegedUsers|  =  0 

2.  Two  Boolean  flags,  one  of  which  is  true  if  and  only  if  the  privileged  user  set  is  empty  and 
the  other  of  which  is  true  if  and  only  if  both  user  sets  are  empty: 

privilegedUsersIsEmpty  =  |privilegedUsers|=0; 

noUsers  =  (privilegedUsersIsEmpty  a  |unprivilegedUsers|=0) 

3.  An  integer  that  holds  the  total  number  of  user  records: 
numberOfUsers  =  |privilegedUsers|  +  |unprivilegedUsers| 
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Example  2.4  (Malformed  always-sections) 

1.  The  simplest  possible  cycle: 

flag  =  -'flag 

2.  A  more  complex  cycle: 

definitionA  =  parameterOne  <  parameterTwo; 

definitionB  =  ((parameterThree  >  parameterFour)  A  -'definitionD); 

definitionC  =  definitionA  v  definitionB; 

definitionD  =  -'definitionC  v  (parameterFour  >  parameterOne) 

2.2.5  Initially  Section 

initially-section  > — »  initialization-guard  — ►  initialization 

(  ||  initialization-guard  — •  initialization)* 

An  initialization-guard  is  a  predicate  on  the  program  parameters  and  definitions  that  de¬ 
pend  only  on  the  program  parameters.  An  initialization  is  a  (unary)  predicate  on  the  program 
variables,  parameters  and  definitions  that  may  contain  variable  names  and  Dynamic  UNITY  op¬ 
erations  (described  in  Section  2.2.8).  This  predicate  constrains  the  initial  state  of  the  program. 
An  initialization  written  with  no  guard  is  considered  to  have  true  as  its  guard. 

The  initially-section  is  used  to  specify  the  initial  values  of  variables  declared  in  the  declare- 
section  (described  in  Section  2.2.3).  All  guards  are  evaluated  simultaneously  at  the  beginning 
of  initialization;  for  each  guard  that  holds  when  evaluated,  the  corresponding  initialization 
predicate  is  guaranteed  to  hold  after  initialization.  If  multiple  guards  are  not  mutually  exclu¬ 
sive,  their  initialization  predicates  must  not  specify  different  values  for  the  same  variable.  In 
addition,  the  inclusion  of  a  process  instantiation  (see  Section  2.2.8. 1)  in  one  or  more  initializa¬ 
tions  incurs  an  obligation  to  prove  that  no  infinite  recursion  of  initially-sections  is  possible. 
An  initially-section  that  contains  conflicting  initializations  or  causes  an  infinite  recursion  is 
considered  malformed. 

Example  2.5  (Well-formed  initializations) 

1.  Nondeterministic  initialization  of  an  integer  variable  to  one  of  two  values: 

anlnteger  =  42  v  anlnteger  =731 

2.  Nondeterministic  initialization  of  an  integer  to  any  positive  value: 


anlnteger  >  0 
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3.  Initialization  of  privileged  and  unprivileged  user  sets  from  passed  parameters  only  if  a 
specific  flag  is  passed: 

initializationFlag  — >  privilegedUsers  =  initialPrivilegedUsers  A 

unprivilegedUsers  =  initialUnprivilegedUsers 


-'initializationFlag  — *  privilegedUsers  =  0  a  unprivilegedUsers  =  0 

4.  Initialization  of  an  inbox,  assigning  it  the  name  “aNewName”: 
mylnbox  =  inbox(“aNewName”) 


Example  2.6  (Malformed  initializations) 

1.  Malformed  nondeterministic  initialization  of  an  integer  variable  to  one  of  two  values: 

true  — *  anlnteger  =  42 


true  — *■  anlnteger  =731 

2.  Malformed  initialization  of  the  privileged  and  unprivileged  user  sets  from  passed  param¬ 
eters  only  if  a  specific  flag  parameter  holds: 

initializationFlag  — *  privilegedUsers  =  initialPrivilegedUsers  a 

unprivilegedUsers  =  initialUnprivilegedUsers 


true  — *  privilegedUsers  =  0  a  unprivilegedUsers  =  0 


2.2.6  Transition  Section 


transition-section 

transition-list 

quantified-transition-list 

transition-list-element 

variable-list 


transition-list 

transition-list-element  \  quantified-transition-list 
(D  transition-list-element  \  quantified-transition-list)* 

(0  variable-list  \  ranges  >  transition-list) 

(variable-list:)1  transition-guard  — *  transition-predicate 
variable-name  (,  variable-name )* 


A  transition-guard  is  a  predicate  on  the  program  parameters,  variables  and  definitions  de¬ 
scribing  only  a  single  program  state  (that  is,  containing  no  primed  variables).  A  transition- 
predicate  is  a  predicate  on  the  program  parameters,  variables  and  definitions  that  may  contain 
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primed  variable  names  and  some  special  operations  detailed  in  Section  2.2.8.  A  transition- 
predicate  is  therefore  a  binary  predicate  on  the  pre-  and  post-  states  of  the  transition.  A  tran¬ 
sition  written  with  no  guard  is  considered  to  have  true  as  its  guard.  Note  that  the  — *  symbol 
in  a  transition  is  not  a  logical  implication,  but  rather  a  separator  between  the  guard  and  the 
transition  (as  found  in  the  guarded  commands  of  CSP  [26]). 

Each  transition  has  an  optional  variable-list  (the  transition  variables  list)  associated  with  it. 
This  list  specifies  all  the  variables  whose  values  can  be  changed  as  a  result  of  the  transition’s 
execution.  Variable  names  in  the  list  that  do  not  appear  in  the  program’s  declare-section  de¬ 
note  temporary  variables  that  exist  only  in  the  scope  of  the  transition.  Every  variable  whose 
primed  name  appears  in  a  transition,  either  explicitly  or  as  part  of  a  messaging  operation,  is 
considered  to  be  in  the  transition  variables  list  for  that  transition  regardless  of  whether  it  is 
listed.  A  transition  variables  list  consisting  only  of  variables  whose  primed  names  appear  in 
the  transition  may  be  omitted  entirely. 

A  quantified  transition  contains  a  variable-list  (the  bound  variables  list),  a  ranges  predicate 
that  constrains  the  ranges  over  which  the  bound  variables  are  quantified,  and  a  transition-list. 
The  bound  variables  list  of  a  quantified  transition  may  not  contain  any  variable  names  that 
appear  in  the  program’s  declare-section,  and  variables  contained  within  the  bound  variables 
list  may  not  appear  primed  in,  or  as  part  of  the  transition- variables  list  of,  any  transition  in  the 
quantified  transition’s  transition-list.  The  ranges  predicate  may  not  contain  primed  variables. 

The  transition-sections  comprise  the  “body”  of  the  program.  They  determine  all  possible 
state  transitions  that  may  take  place  during  the  program’s  execution.  A  transition  is  satisfiable 
if,  for  every  program  state  where  its  guard  holds,  its  transition-predicate  can  be  satisfied  by 
establishing  a  post-state  in  which  every  variable  whose  value  differs  from  that  in  the  pre-state 
appears  in  the  transition- variables  list.  A  transition’s  satisfiability  is  therefore  independent  of 
program  executions,  as  it  depends  only  on  the  guard,  the  transition-predicate,  and  the  types 
of  all  variables  in  the  transition- variables  list. 

In  addition  to  satisfiability,  we  require  that  the  quantihcation(s)  of  a  Dynamic  UNITY  tran¬ 
sition  be  countable.  An  unsatishable  Dynamic  UNITY  transition,  or  one  with  an  uncountable 
quantification,  is  considered  malformed.  While  we  do  not  explicitly  disallow  malformed  transi¬ 
tions,  it  is  important  to  note  that  we  make  no  guarantees  about  the  behavior  of  Dynamic  UNITY 
systems  with  malformed  transitions. 

Clearly,  it  is  not  always  practical  (or  even  possible)  to  tell  whether  or  not  a  particular  transi¬ 
tion  is  unsatishable,  because  such  a  determination  may  itself  involve  an  intractable  or  undecid- 
able  computation.  However,  we  make  it  a  proof  obligation  that  all  transitions  must  be  explicitly 
proven  satisfiable.  Thus,  it  is  possible  to  write  a  Dynamic  UNITY  program  that  contains  only 
satisfiable  transitions,  but  not  be  able  to  prove  the  correctness  of  that  program  because  it  isn’t 
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possible  to  prove  the  satisfiability  of  the  transitions. 

In  addition,  there  is  an  important  distinction  between  malformed  transitions  and  uncom¬ 
putable  transitions.  An  uncomputable  transition  is  one  where  the  guard  or  postcondition  is 
uncomputable;  for  example,  the  guard,  “X  is  a  nonterminating  Turing  machine,”  is  uncom¬ 
putable,  because  computing  it  would  require  a  solution  to  the  halting  problem.  However,  we 
can  still  make  guarantees  about  uncomputable  transitions  provided  that  they  are  satishable 
(such  as,  “X  is  a  nonterminating  Turing  machine  — *  Y'  =  X”).  We  can  therefore  prove  the  cor¬ 
rectness  of  Dynamic  UNITY  systems  which  contain  uncomputable  transitions,  even  though  we 
can  never  implement  these  systems  on  real  computers.  The  differences  between  the  Dynamic 
UNITY  systems  we  can  prove  the  correctness  of  and  the  ones  we  can  actually  implement  are 
discussed  further  in  Chapter  7. 

Example  2.7  (Well-formed  transitions) 

1.  Increment  an  integer  variable  by  1  if  its  value  is  less  than  the  value  of  integer  parameter 
MAXINT: 

anlnteger  <  MAXINT  — ►  anlnteger'  =  anlnteger  +  1 

2.  Increment  every  integer  variable  in  the  set  bigSet: 
bigSet'  =  {i  |  i  e  bigSet  >  i  +  1} 

Example  2.8  (Malformed  transitions) 

1.  Increment  an  integer  variable  by  1  if  its  value  is  less  than  the  value  of  integer  parameter 
MAXINT,  with  an  additional  constraint: 

anlnteger  <  MAXINT  — »  anlnteger'  =  anlnteger  +  1  a  anlnteger'  <  MAXINT 

2.  Perform  any  computation,  by  establishing  the  postcondition  false: 
false 

Example  2.9  (Quantified  transitions) 

1.  Fill  in  the  values  of  an  identity  matrix  of  dimension  N: 

<  0  i,  j|0<i<NA0<j<N[> 

i  =  j  —  matrix' [i,j]  =  1 
0  i  +  j  — *  matrix' [ij]  =  0  ) 

2.  Remove  all  the  integers  from  set  S,  one  at  a  time  (the  type  operation  is  discussed  in  Section 


2. 2. 8.4): 

( 0  i  |  i  E  S  a  i.type  =  integer  >  S'  =  S  \  {i}) 
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2.2.7  System  Structure 

system  > — ►  system  system-name 
(type  type-section)1 
(, program-section )+ 

end 

A  system-name  is  any  string  of  letters  and  digits.  There  are  no  restrictions  on  this  string;  it 
is  currently  used  only  for  referring  to  the  system  in  proofs  and  discussions.  The  type-section, 
program-section  and  initially-section  are  exactly  as  described  previously. 

A  Dynamic  UNITY  system  contains  one  or  more  component  programs,  with  at  most  one 
designated  as  an  initial  program  (as  described  in  Section  2.2.1).  A  system  containing  no  initial 
program  is  legal,  but  such  a  system  will  have  no  transitions  and  will  therefore  never  do  anything. 

2.2.8  Operations 

In  addition  to  variable  state  changes,  Dynamic  UNITY  supports  operations  for  process  instanti¬ 
ation,  process  destruction,  messaging,  and  introspection  on  variable  types.  In  this  section,  we 
describe  the  syntax  of  these  operations  and  the  contexts  in  which  each  can  be  used. 

2.2.8. 1  Process  Instantiation 

Dynamic  UNITY  processes  are  instantiated  with  the  new  operation,  which  has  the  following 
syntax: 


new-operation  > — ►  reference-name  =  new  program-name  (passed-parameters) 

passed-parameters  > — «  parameter  (,  parameter)* 

A  reference-name  is  the  name  of  a  variable  of  type  program-name,  which  will  contain  a 
reference  to  the  instantiated  process  as  a  postcondition  of  the  new  operation.  A  program- 
name  is  exactly  as  described  in  Section  2.2.1,  and  a  parameter  is  any  variable  or  value.  The 
types  of  the  parameters  in  the  passed-parameters  list  must  match  the  types  of  the  parameters 
in  the  parameter-list  of  the  program  being  instantiated. 

All  parameters  in  Dynamic  UNITY  are  passed  by  value.  The  values  held  by  the  parameters 
at  the  execution  of  the  new  operation  are  copied  locally  for  the  new  process,  and  are  treated  as 
constants  by  the  new  process  during  its  execution.  The  new  process’  initially-section  is  executed 
immediately  as  part  of  the  new  operation,  and  its  transitions  are  available  for  execution  (that 
is,  they  can  be  chosen  by  the  scheduler)  immediately  after  the  new  operation. 
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Process  instantiations  can  occur  in  both  the  initially-section  and  the  transition-sections  of 
a  program.  Therefore,  the  reference-name  can  be  either  primed  (a  variable  assignment  in  a 
transition-section)  or  unprimed  (an  initialization). 

2. 2. 8.2  Process  Destruction 

A  Dynamic  UNITY  process  can  halt  its  execution  with  the  stop  operation.  The  syntax  for  this 
operation  is  the  keyword  stop,  used  as  a  conjunct  or  disjunct  in  a  transition. 

When  a  stop  operation  is  executed,  the  process’s  transitions  are  removed  from  the  system 
and  no  more  changes  to  the  process’s  state  (excluding  the  states  of  its  mailboxes)  ever  occur. 
A  process  that  executes  a  stop  is  effectively  destroyed.  All  messages  sent  by  the  process, 
including  those  sent  in  the  same  transition  as  the  stop,  are  delivered  by  the  message-passing 
system  just  as  they  would  have  been  without  the  process  destruction.  Similarly,  all  messages 
sent  to  the  process  by  other  processes  in  the  system  are  delivered  to  its  inboxes,  even  though 
the  process  will  never  be  able  to  read  them. 

When  stop  is  used  as  a  disjunct  in  a  transition,  the  process  may  or  may  not  be  destroyed 
after  that  transition  is  completed;  such  nondeterministic  process  destruction  can  be  used  to 
simulate  process  failures. 

In  the  Dynamic  UNITY  formalism,  the  state  of  a  destroyed  process  remains  in  the  system 
perpetually.  This  facilitates  the  construction  of  proofs  that  depend  on  the  final  states  of  de¬ 
stroyed  processes.  However,  in  an  actual  implementation,  a  destroyed  process’s  state  would 
most  likely  be  removed  from  memory  for  space  and  efficiency  considerations. 

2.2.8.3  Messaging 

Dynamic  UNITY  contains  a  messaging  system  that  uses  incoming  and  outgoing  message  queues. 
The  Dynamic  UNITY  type  inbox  implements  incoming  message  queues,  and  support  operations 
that  allow  processes  to  receive  and  inspect  incoming  messages.  Each  Dynamic  UNITY  process 
has  a  single  outgoing  message  queue  (called  an  outbox)  that  it  can  use  to  send  messages  to 
other  processes.  The  following  describes  the  internal  structure  of  inboxes  and  outboxes,  as 
used  in  proofs  of  correctness;  however,  Dynamic  UNITY  transitions  cannot  read  or  modify 
any  of  this  internal  structure  directly,  and  can  only  interact  with  the  messaging  system  using 
the  messaging  operations  described  later  in  this  section.  This  restriction  prevents  Dynamic 
UNITY  programs  from  relying  on  any  specific  behavior  of  the  messaging  system  (such  as  its 
interleaving  with  the  execution  of  regular  Dynamic  UNITY  transitions)  other  than  the  fact  that 
it  establishes  point-to-point  first-in-first-out  channels. 

Inboxes  are  treated  as  named  sequences  of  records.  They  have  three  associated  attributes: 
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name,  a  string  that  uniquely  identifies  the  inbox  within  its  process;  length  (usually  abbreviated 
len),  the  number  of  messages  in  the  inbox;  and  count  (usually  abbreviated  cnt),  the  index  of 
the  next  message  to  be  read. 

The  outbox  for  each  Dynamic  UNITY  process  is  also  treated  as  a  sequence  of  records,  and 
has  one  attribute  associated  with  it — length  (usually  abbreviated  len),  the  number  of  messages 
that  have  been  sent  by  the  process.  An  additional  attribute,  count  (usually  abbreviated  cnt), 
is  derived  from  the  delivered  fields  of  the  message  records  in  an  outbox  (described  below); 
it  is  the  number  of  delivered  fields  that  have  the  value  true,  which  is  exactly  the  number  of 
messages  in  the  outbox  that  have  been  delivered. 

Inboxes  and  outboxes  are  sequences  of  unbounded  length,  preserving  the  entire  message 
history  for  all  processes  in  the  system.  This  facilitates  the  construction  of  proofs  that  depend 
on  message  histories  and  message  ordering.  However,  in  an  actual  implementation,  message 
histories  would  most  likely  be  kept  small  for  space  and  efficiency  considerations. 

Each  record  contained  in  an  inbox  or  outbox  has  multiple  fields:  records  in  inboxes  have  2 
fields,  while  records  in  outboxes  have  4.  These  fields  are  defined  as  follows: 

•  The  process  field  (usually  abbreviated  proc)  appears  in  both  inbox  and  outbox  records.  In 
an  inbox  record,  it  contains  a  reference  to  the  process  that  sent  the  message  contained  in 
that  record.  In  an  outbox  record,  it  contains  a  reference  to  the  process  that  will  receive 
(or  has  received)  the  message  contained  in  that  record. 

•  The  mailbox  field  (usually  abbreviated  mbox)  appears  only  in  outbox  records.  It  contains 
the  name  of  the  inbox  to  which  the  message  contained  in  the  record  will  be  (or  has  been) 
delivered. 

•  The  message  field  (usually  abbreviated  msg)  appears  in  both  inbox  and  outbox  records. 
In  an  inbox  record,  it  contains  the  message  data  that  was  received.  In  an  outbox  record, 
it  contains  the  message  data  that  will  be  (or  has  been)  sent. 

•  The  delivered  field  (usually  abbreviated  del)  appears  only  in  outbox  records.  It  contains  a 
Boolean  value  that  indicates  whether  or  not  the  message  contained  in  the  record  has  been 
delivered  to  its  destination  (it  is  false  if  the  message  has  not  been  delivered,  and  true  if 
it  has). 

The  attributes  of  outboxes  and  inboxes  are  all  updated  atomically  to  reflect  the  new  state 
of  the  messaging  system  when  a  message  delivery  occurs.  Since  these  attributes  are  not  ob¬ 
servable  by  Dynamic  UNITY  programs,  their  updates  do  not  actually  have  to  be  atomic  in  an 
implementation  of  a  Dynamic  UNITY  system  as  long  as  the  messaging  system  correctly  im- 
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plements  reliable  point-to-point  first-in  first-out  channels.  They  are  used  only  in  proofs  of 
correctness,  and  in  our  detailed  specification  of  the  Dynamic  UNITY  execution  model. 

Dynamic  UNITY  programs  use  messaging  operations  to  access  the  mailbox  data  structures 
we  have  described,  and  cannot  access  these  structures  by  any  other  means.  Outboxes  support 
a  single  operation  that  allows  for  the  sending  of  messages  (or  sequences  of  messages).  Inboxes 
support  four  operations  that  allow  for  the  detection  of  available  messages,  reading  of  the  next 
available  message,  removal  of  the  next  available  message,  and  reading  of  an  inbox’s  name.  The 
syntax  and  an  overview  of  the  semantics  for  these  operations  are  described  in  the  remainder 
of  this  section.  Semantics  for  these  operations  are  described  in  detail  with  the  semantics  of 
the  messaging  system  in  Section  2.3.2. 

Send  The  send  operation  on  an  outbox  causes  a  message  (sequence  of  messages)  to  be  sent 
to  a  destination  inbox  (sequence  of  destination  inboxes).  Its  syntax  is  as  follows: 

send-operation  > — -  send  ( message-send-list ) 

message-send-list  > — *  message-send  (,  message-send)* 

message-send  > — «  process-reference ,  inbox-name,  message 

A  process-reference  is  a  variable  or  parameter  that  contains  a  reference  to  a  process.  An 
inbox-name  is  a  string,  which  is  the  name  of  the  inbox  to  which  the  associated  message  will  be 
sent.  A  message  is  any  value  or  variable. 

Semantically,  a  send  operation  is  a  manipulation  of  the  outbox  sequence  that  causes  one  or 
more  appropriate  outbox  records  to  be  appended  to  the  sequence.  When  a  send  operation  in¬ 
cludes  more  than  one  message-send,  the  message  records  are  appended  to  the  outbox  sequence 
in  the  order  in  which  they  are  listed.  Quantifier-like  syntax  may  be  used  to  send  messages  to  a 
set  of  inboxes;  this  is  shown  in  the  example  below.  The  quantification  of  a  message  send  must 
be  finite— a  message  send  with  an  infinite  quantification  is  considered  malformed.  While  we 
do  not  explicitly  disallow  malformed  message  sends,  we  make  no  guarantees  about  Dynamic 
UNITY  systems  that  contain  malformed  message  sends. 

The  send  operation  can  be  used  in  both  the  initially-section  and  the  transition-sections  of 
a  program.  If  the  send  operation  is  used  in  two  or  more  different  initializers  of  a  program,  no 
ordering  guarantee  is  provided  with  respect  to  the  sends  (they  are  equally  likely  to  occur  in  any 
of  the  possible  orderings). 

Example  2.10  (Quantified  Message  Sends) 

1.  Send  a  different  message  of  type  “MessageType”  to  the  inbox  named  “in”  belonging  to 
each  process  in  set  P: 

send  ((,  p  |  p  e  P  >  p,  “in”,  MessageType(p))) 
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2.  Send  identical  messages  to  each  inbox  whose  name  is  contained  in  set  I  belonging  to  each 
process  in  set  P: 

send  ((,  p,  i  |  p  e  P  A  i  E  I  >  p,  i,  theMessage)) 

Probe  The  probe  operation  on  an  inbox  evaluates  to  the  Boolean  value  true  if  there  is  a  mes¬ 
sage  that  has  been  placed  in  the  inbox  but  has  not  been  advanced  past  with  the  advance  oper¬ 
ation,  and  evaluates  to  the  Boolean  value  false  otherwise.  Its  syntax  is  inbox-var. probe,  where 
inbox-var  is  the  inbox  variable  to  probe.  The  probe  operation  is  shorthand  for  a  comparison 
between  the  inbox’s  current  message  counter  and  the  number  of  messages  in  the  inbox;  it  can 
therefore  be  used  anywhere  a  predicate  that  makes  such  a  comparison  can  be  used. 

Current  The  current  operation  on  an  inbox  allows  read-only  access  to  the  current  message  in 
the  inbox  (as  determined  by  the  inbox’s  cnt  attribute).  Its  syntax  is  inbox-var. current. 

The  current  operation  can  be  used  on  the  right-hand  side  of  assignments,  as  well  as  in  any 
non-assignment  predicate.  It  is  handled  exactly  as  a  record  containing  the  inbox  record  fields 
described  above:  the  actual  message  data  is  inbox-var. current.msg,  and  the  reference  to  the 
sending  process  is  inbox-var. current.proc. 

If  no  messages  have  ever  been  placed  in  the  inbox,  or  if  the  inbox  has  been  advanced  past 
its  last  message,  the  current  operation  returns  a  record  containing  the  null  set  as  its  message 
data  and  the  null  process  as  its  sender. 

Advance  The  advance  operation  on  an  inbox  advances  the  inbox  to  the  next  message.  Its 
syntax  is  inbox-var. advance.  The  advance  operation  is  shorthand  for  an  increment  of  the  in¬ 
box’s  current  message  counter;  it  can  therefore  be  used  anywhere  a  predicate  that  increments 
a  variable  can  be  used. 

Name  The  name  operation  on  an  inbox  allows  read-only  access  to  the  inbox’s  name  as  a  string. 
Its  syntax  is  inbox-var. name.  It  can  be  used  anywhere  a  string  (or  a  variable  of  type  string)  can 
be  used. 

2. 2. 8.4  Introspection 

In  addition  to  the  process  and  messaging  operators,  Dynamic  UNITY  supports  operations  that 
perform  limited  introspection  on  entities  (such  as  messages  received  in  an  inbox).  These  op¬ 
erations  allow  a  process  to  determine  the  type  of  an  entity,  as  well  as  its  length  (for  arrays  or 
sequences)  or  cardinality  (for  sets).  There  is  also  an  operation  that  allows  a  process  to  obtain 
a  reference  to  itself. 
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Type  The  type  operation  allows  a  process  to  determine  and  act  on  the  type  of  a  Dynamic 
UNITY  entity.  Its  syntax  is  entity.type,  where  entity  is  a  variable  or  an  entity  assignable  to  a 
variable  (such  as  myJnhox.current.msg).  It  is  typically  used  in  comparisons  with  type  names 
or  type  specifiers  for  conditional  message  receives,  as  shown  in  the  examples  below,  but  can 
be  used  elsewhere.  Type  names  used  in  a  comparison  must  be  the  names  of  either  primitive 
types  or  types  declared  in  the  scope  of  the  comparison;  the  elimination  of  potential  confusion 
about  the  interpretation  of  type  comparisons  is  the  main  reason  why  types  and  variables  are 
not  allowed  to  have  identical  names. 

Example  2.11  (Typical  usage  of  the  type  operation) 

1.  Receive  a  message  into  variable  theMessage  only  if  the  message  data  is  of  type  “myDe- 
siredType.” 

mylnbox.probe  A  mylnbox.current.msg.type  =  myDesiredType  — > 

(theMessage'  =  myInbox.current.msg)  A  mylnbox.advance 

2.  Receive  a  message  into  variable  theMessage  only  if  the  message  data  is  of  the  same  type 
as  the  variable. 

mylnbox.probe  A  mylnbox.current.msg.type  =  theMessage.type  — * 

(theMessage'  =  myInbox.current.msg)  A  mylnbox.advance 


Length  The  length  operation  allows  a  process  to  determine  the  current  number  of  elements 
in  an  array  or  a  sequence,  or  the  length  of  a  string;  it  cannot  be  used  on  mailboxes.  Its  syntax 
is  enfify.length,  where  entity  is  a  variable  holding  a  value  of  an  array,  sequence  or  string  type. 
The  analogous  operation  for  a  set,  cardinality,  is  performed  using  the  standard  mathematical 
syntax  for  sets  (|set|).  The  length  (or  cardinality)  operation  results  in  an  integer  constant,  and 
it  can  be  used  anywhere  an  integer  constant  can  be  used. 

This  The  this  operation  allows  a  process  to  obtain  a  reference  (of  type  process)  to  itself.  Its 
syntax  is  the  keyword  this,  used  in  a  transition  within  the  process,  and  it  can  be  used  anywhere 
a  value  of  type  process  can  be  used. 

2.3  Dynamic  UNITY  Semantics 

We  now  describe  the  semantics  of  Dynamic  UNITY,  paying  particular  attention  to  the  areas 
where  they  differ  from  the  semantics  of  the  original  UNITY  formalism. 
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2.3.1  Execution  Model 

Dynamic  UNITY’S  execution  model  is  similar  to  UNITY’S  execution  model,  in  that  both  atom¬ 
ically  execute  a  single  statement  at  a  time  from  a  set  of  statements  in  a  weakly  fair  manner. 
However,  this  is  where  the  similarities  end.  While  a  UNITY  program  has  a  static  set  of  guarded 
assignment  statements  that  are  all  subject  to  weak  fairness,  a  Dynamic  UNITY  system  has  a 
dynamic  set  of  processes,  where  each  process  has  a  set  of  guarded  transitions,  some  of  which 
are  subject  to  weak  fairness  and  some  of  which  are  not.  By  including  the  ability  to  create  tran¬ 
sitions  that  are  not  subject  to  fairness  constraints,  Dynamic  UNITY  can  more  accurately  model 
real  distributed  systems  in  which  particular  events  (such  as  requests  in  a  resource  allocation 
system)  may  not  occur  in  a  fair  manner.  The  definition  of  weak  fairness  itself  is  different  in 
Dynamic  UNITY,  because  the  set  of  transitions  available  in  the  system  can  change.  We  first 
define  a  weakly  fair  transition,  and  then  introduce  our  definition  for  weak  fairness: 

Definition  2.1  (Weakly  Fair  Transition)  A  weakly  fair  transition  in  a  Dynamic  UNITY  sys¬ 
tem  is  an  instantiation  of  a  transition-statement  within  the  fair-transition  section  of  a  Dynamic 
UNITY  program,  specified  by  the  process  to  which  it  belongs  and  any  quantifying  terms  used  to 
generate  it. 

This  definition  means  that  two  different  instantiations  of  the  same  Dynamic  UNITY  program 
have  two  different  sets  of  weakly  fair  transitions.  It  also  means  that  a  quantified  transition  is 
considered  not  as  a  single  weakly  fair  transition,  but  as  a  number  of  weakly  fair  transitions 
(depending  on  the  range  of  the  quantification).  Given  this  definition  for  a  weakly  fair  transition, 
the  definition  of  weak  fairness  for  Dynamic  UNITY  systems  is  as  follows: 

Definition  2.2  (Weak  Fairness)  In  every  computation  of  a  Dynamic  UNITY  system,  every 
weakly  fair  transition  is  infinitely  often  either  selected  or  not  present  in  the  system. 

This  definition  implies  that  a  transition  that  remains  in  the  system  forever  will  execute 
infinitely  often.  It  does  not,  however,  imply  that  a  transition  that  is  merely  present  in  the  system 
infinitely  often  will  execute  infinitely  often.  Weak  fairness  will  be  discussed  in  more  detail  when 
we  formalize  the  execution  model  in  Chapter  3;  the  following  is  an  informal  execution  model 
for  Dynamic  UNITY  systems: 

In  each  system  step,  at  most  one  state  transition  occurs.  Transitions  are  selected  from 
the  fair-transition  and  unfair-transition  sections  (described  in  Section  2.2.6)  of  the  processes 
currently  running  in  the  system.  When  a  transition  is  selected,  its  precondition  is  evaluated. 
If  it  evaluates  to  true,  the  transition  is  executed  atomically  and  its  postcondition  holds  at  the 
end  of  this  execution,  and  if  it  evaluates  to  false,  the  state  of  the  system  is  left  unchanged. 
If  a  transition  is  selected  whose  precondition  evaluates  to  true  and  whose  postcondition  is 
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system  ExampleSystem 

initial-program  ExampleSystemComponent 

declare 

theSet:  set  {integer} 

initially 

theSet  =  0 

fair-transition 

(1)  true  — ►  <3  i  |  i  £  theSet  >  theSet'  =  theSet  u  {i}) 

(2)  0  true  — *  stop 

(3)  D  <0i  I  i  e  theSet  >  i  >  731  — ►  p:  p'  =  new  ExampleSystemComponent) 


end 

end 


Specification  2.1:  An  example  system  used  to  illustrate  a  changing  transition  set 


unsatishable  at  that  point  in  the  execution,  we  cannot  say  anything  about  the  state  of  the 
system  which  results.  It  is  therefore  important,  when  constructing  Dynamic  UNITY  systems, 
to  ensure  that  they  contain  no  malformed  transitions. 

In  an  infinite  execution  of  the  system,  every  transition  in  the  fair-transition  section  of  each 
running  program  is  guaranteed  to  be  selected  in  a  manner  consistent  with  the  weak  fairness  def¬ 
inition.  No  guarantee  is  made  about  how  often  each  transition  in  the  unfair-transition  section 
of  each  program  is  selected.  A  system  step  can  result  in  the  addition  or  removal  of  processes 
from  the  system,  as  well  as  the  addition  or  removal  of  quantified  transition  instances  due  to 
state  variable  changes.  We  now  present  a  simple  system,  and  trace  an  example  execution  to 
illustrate  how  the  set  of  transitions  in  the  system  changes. 

Example  2.12  (An  illustration  of  a  changing  transition  set) 

The  simple  Dynamic  UNITY  system  of  Specification  2.1  contains  processes  that  have  a  single 
set  as  a  state  variable,  and  that  can  create  new  processes  and  destroy  themselves.  It  illustrates 
the  changing  nature  of  the  transition  set  in  a  Dynamic  UNITY  system. 

This  system  consists  of  one  type  of  process,  which  has  only  one  state  variable:  a  set  of 
integers.  Its  three  transitions  have  the  following  effects: 

1.  Adds  an  integer  to  the  set,  ensuring  that  the  added  integer  was  not  already  in  the  set.  We 
note  that  this  addition  is  not  fair,  even  though  the  transition  is  a  fair  transition;  while  we 
guarantee  that  this  transition  executes  infinitely  often,  we  do  not  guarantee  that  every 
integer  i  will  eventually  become  part  of  theSet. 
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2.  Stops  the  process. 

3.  Expands  to  a  transition  for  every  integer  in  the  set,  which  instantiates  a  new  process  if  the 
integer  is  greater  than  731.  For  example,  if  the  set  consists  of  the  integers  1013,  -5,  and 
0,  this  would  expand  to  the  following  three  transitions  (recall  that  the  “p:”  syntax  defines 
a  temporary  variable  in  the  scope  of  its  associated  transition): 

1013  >  731  — ►  p:  p'  =  new  ExampleSystemComponent 

-5  >  731  — ►  p:  p'  =  new  ExampleSystemComponent 

0  >  731  — ►  p:  p'  =  new  ExampleSystemComponent 

We  denote  the  transitions  of  the  system  by  a  process  identifier  (A,  B,  C,  ...),  a  number  (taken 

from  the  program  above),  and,  when  necessary,  a  subscript  indicating  a  particular  instantiation 
of  a  quantified  transition.  We  subscript  state  variables  with  their  corresponding  process  iden¬ 
tifiers  for  clarity,  since  we  are  presenting  the  system’s  transitions  as  one  combined  set.  Using 
these  conventions,  one  legal  execution  of  this  system  can  be  described  as  follows: 

1.  Initialization:  A  process  (to  which  we  assign  the  identifier  A)  is  instantiated  from  the  sys¬ 
tem’s  initial  program.  A’s  state  variable  theSet  is  initialized  to  the  empty  set.  Therefore, 
the  set  of  transitions  in  the  system  is: 

(Al)  true  — ►  (3  i  |  i  theSetA  t>  theSetA7  =  theSetA  u  {i}> 

(A2)  true  — *  stop 

2.  Transition  (Al)  is  chosen;  the  integer  5  is  added  to  theSetA ■  The  set  of  transitions  in  the 
system  changes  to  the  following: 

(Al)  true  — ►  (3  i  |  i  theSetA  t>  theSetA7  =  theSetA  u  {i}) 

(A2)  true  — *  stop 

(A3 5)  5  >  731  — *  p:  p7  =  new  ExampleSystemComponent 

3.  Transition  (A3 5)  is  chosen.  The  precondition  does  not  hold,  so  no  state  change  occurs, 
and  no  change  is  made  to  the  transition  set. 

4.  Transition  (Al)  is  chosen;  the  integer  1013  is  added  to  theSetA-  The  set  of  transitions  in 
the  system  changes  to  the  following: 

(Al)  true  — ►  (3  i  |  i  theSetA  t>  theSetA7  =  theSetA  u  {i}> 

(A2)  true  — ►  stop 

(A3 5)  5  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
(A3ioi3)  1013  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
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5.  Transition  (Al)  is  chosen;  the  integer  -7  is  added  to  theSetA ■  The  set  of  transitions  in  the 
system  changes  to  the  following: 

(Al)  true  — ►  <3  i  |  i  <£  theSetA  >  theSetA7  =  theSetA  u  {i}) 

(A2)  true  — *  stop 

(A3_7)  -7  >  731  — *  p:  p'  =  new  ExampleSystemComponent 
(A3s)  5  >  731  — *  p:  p'  =  new  ExampleSystemComponent 
(A3ioi3)  1013  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 

6.  Transition  (A31013)  is  chosen.  The  precondition  holds,  so  a  new  process  (to  which  we 
assign  the  identifier  B)  is  created.  B’s  state  variable  theSet  is  initialized  to  the  empty  set. 
Therefore,  the  set  of  transitions  in  the  system  changes  to  the  following: 

(Al)  true  — *  (3  i  |  i  <£  theSetA  t>  theSetA7  =  theSetA  u  {i}> 

(A2)  true  — *  stop 

(A3_7)  -7  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
(A3 5)  5  >  731  — *  p:  p7  =  new  ExampleSystemComponent 
(A3ioi3)  1013  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
(Bl)  true  — ►  (3  i  |  i  <£  theSetB  o  theSetB7  =  theSetB  u  {i}> 

(B2)  true  — *  stop 

7.  Transition  (Bl)  is  chosen;  the  integer  731  is  added  to  theSet B.  The  set  of  transitions  in 
the  system  changes  to  the  following: 

(Al)  true  — ►  (3  i  |  i  <£  theSetA  >  theSetA7  =  theSetA  u  {i}> 

(A2)  true  — -  stop 

(A3_7)  -7  >  731  — *  p:  p7  =  new  ExampleSystemComponent 
(A3 5)  5  >  731  — -  p:  p7  =  new  ExampleSystemComponent 
(A3ioi3)  1013  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
(Bl)  true  — »  (3  i  |  i  theSetB  >  theSetB7  =  theSetB  u  {i}> 

(B2)  true  — »  stop 

(B3731)  731  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 

8.  Transition  (A2)  is  chosen,  removing  process  A  from  the  system.  The  set  of  transitions  in 
the  system  changes  to  the  following: 

(Bl)  true  — ►  (3  i  |  i  <£  theSetB  >  theSetB7  =  theSetB  u  {i}> 

(B2)  true  — »  stop 

(B3731)  731  >  731  — ►  p:  p7  =  new  ExampleSystemComponent 
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9.  Transition  (B2)  is  chosen,  removing  process  B  from  the  system.  The  set  of  transitions  in 
the  system  is  now  empty,  so  execution  of  the  system  terminates. 

We  note  that,  while  this  particular  execution  of  this  system  terminates,  not  all  executions 
of  it  do;  there  are  many  possible  executions  of  this  system  that  run  forever. 

2.3.2  Messaging 

Dynamic  UNITY’S  messaging  system  implements  first-in  first-out  asynchronous  messaging  be¬ 
tween  every  outbox/inbox  pair.  That  is,  all  messages  sent  from  a  particular  outbox  to  a  par¬ 
ticular  inbox  arrive  in  the  order  in  which  they  were  sent.  The  messaging  system  makes  no 
guarantees  about  the  ordering  of  messages  sent  to  different  inboxes  from  the  same  outbox, 
nor  does  it  make  any  guarantees  about  the  ordering  of  messages  sent  to  the  same  inbox  from 
different  outboxes. 

Semantically,  inboxes  and  outboxes  are  treated  as  sequences  of  records,  as  discussed  in 
Section  2. 2. 8. 3.  Each  inbox  (outbox)  has  a  name,  as  well  as  two  attributes  that  indicate  how 
many  messages  have  been  placed  into  the  inbox  (outbox)  and  how  many  messages  have  been 
read  (sent).  Additionally,  each  message  record  in  an  inbox  (outbox)  has  two  (three)  attributes 
that  contain  the  message  data  and  information  about  the  message’s  source  (destination),  and 
each  message  record  in  an  outbox  has  a  flag  indicating  whether  or  not  that  message  has  been 
delivered  to  its  destination  inbox.  For  the  purposes  of  our  semantics,  these  attributes  are 
updated  atomically:  when  a  message  is  delivered,  the  attributes  of  the  source  outbox  and  the 
destination  outbox  are  all  updated  within  the  same  atomic  operation  to  reflect  the  delivery  of 
that  message. 

Both  inboxes  and  outboxes  are  empty  when  they  are  initially  constructed  (either  at  process 
initialization  time  or,  for  inboxes  only,  when  instantiated  during  execution).  All  modifications 
of  inbox  and  outbox  contents  and  attributes  are  made  either  as  part  of  normal  transitions  that 
use  messaging  operations  during  program  execution,  or  by  the  messaging  system  itself.  We 
now  describe  the  semantics  of  the  messaging  operations. 

2.3.2. 1  Messaging  Operations 

As  described  in  Section  2. 2. 8. 3,  outboxes  support  a  single  operation  that  allows  for  the  sending 
of  messages  or  sequences  of  messages,  while  inboxes  support  three  operations  that  allow  for 
the  reception  of  messages  and  the  detection  of  available  messages.  These  operations  are  exactly 
equivalent  to  the  following  predicates,  which  use  or  modify  the  contents  and  attributes  of 
mailboxes: 
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Send  The  send  operation  on  an  outbox  is  equivalent  to  an  appropriate  increment  of  that 
outbox’s  len  attribute  and  a  corresponding  modibcation  of  the  outbox’s  contents.  Each  process 
has  a  single  outbox,  which  we  represent  by  O  for  the  purposes  of  this  section.  Since  the  send 
operation  can  take  multiple  forms,  we  give  examples  of  each  with  their  equivalent  predicates: 

Example  2.13  (Send  operations) 

1.  A  simple  send  operation— send(targetProcess,  targetlnboxName,  sentMessage)— is  equiv¬ 
alent  to  the  following  predicate: 

O'  [O  .len]  =  {targetProcess,  targetlnboxName,  sentMessage}  A 

O'.len  =  (9  .len  +  1 

2.  A  multiple  send  operation— send(targetProcl,  targetlnboxl,  sentMessagel,  targetProc2, 
targetInbox2,  sentMessage2)— is  equivalent  to  the  following  predicate: 

(9'[(9.1en]  =  {targetProcl,  targetlnboxl,  sentMessagel}  A 
O' [O .len  +  1]  =  {targetProc2,  targetInbox2,  sentMessage2}  a 

<9'.len  =  (9  .len  +  2 

3.  A  quantified  send  operation— send((,  pipe  targetProcesses  >  p,  “inboxName”, 
MessageType(p))) — is  equivalent  to  the  following  predicate  (recall  that  the  quantification 
of  a  quantified  message  send  must  be  finite): 

(V  p  |  p  G  targetProcesses  > 

(3  i  |  O.len  <  i  <  O'. len  >  0'[i]  =  {p,  “inboxName”,  MessageType(p)}))  A 
O'. len  =  O.len  +  |  targetProcesses  | 


Probe  The  operation  inbox-var. probe  is  equivalent  to  the  predicate  inbox-var. cnt  <  inbox- 
var. len,  which  compares  the  cnt  and  len  attributes  of  an  inbox.  If  the  predicate  evaluates  to 
true,  then  there  is  a  message  on  the  inbox  that  has  not  yet  been  read. 

Current  The  operation  inbox-va r. current  is  equivalent  to  the  term  inbox-var[inbox-var. cnt]; 
it  is  the  message  record  contained  at  the  index  of  the  inbox  corresponding  to  the  number  of 
messages  which  have  already  been  read.  Typically,  the  current  operation  is  used  to  access 
one  or  more  fields  of  the  message  record,  as  in  ;nbox-var.current.msg  (to  retrieve  the  actual 
message  content). 
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Advance  The  operation  inbox-var. advance  is  equivalent  to  the  predicate  inbox-var' . cnt  = 
inbox-var. cnt  +  1,  which  increments  by  1  the  number  of  messages  which  have  been  read  from 
the  inbox.  This  equivalence  holds  regardless  of  the  value  of  the  inbox’s  len  attribute,  which 
means  that  it  is  possible  for  cnt  to  exceed  len.  This  is  acceptable  because  we  have  defined 
inboxes  as  infinite  sequences,  although  it  will  result  in  default  data  being  read  from  the  inbox 
until  enough  messages  are  placed  in  the  inbox  for  len  to  catch  up  to  cnt.  To  avoid  this  (usually 
undesirable)  behavior,  advance  should  be  used  on  an  inbox  only  when  a  probe  of  the  inbox 
evaluates  to  true. 
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Chapter  3 

Verification  of  Dynamic  UNITY 
Specifications 


In  this  chapter,  we  introduce  and  discuss  a  logic  for  the  verification  of  Dynamic  UNITY  spec¬ 
ifications.  Verification  of  individual  programs  in  a  Dynamic  UNITY  system  is  very  similar  to 
verification  of  UNITY  programs  using  UNITY  logic  [8],  while  verification  of  Dynamic  UNITY  sys¬ 
tems  in  their  entirety  is  accomplished  by  first  verifying  properties  of  the  systems’  component 
programs  and  then  reasoning  about  their  messaging  interactions. 

We  first  present  some  notation  and  basic  concepts  that  we  will  use  throughout  this  chapter 
and  during  our  proofs  in  the  example  chapters;  then,  we  discuss  the  specific  proof  rules  and 
theorems  that  provide  a  basis  for  proving  properties  of  Dynamic  UNITY  programs  and  systems. 

3.1  Basic  Concepts  and  Conventions 

3 . 1 . 1  Quantification 

We  use  various  types  of  quantification  while  stating  the  proof  rules  and  theorems  of  this  chap¬ 
ter,  as  well  as  in  our  proofs  of  Dynamic  UNITY  specifications.  Our  notation  for  quantification 
is  taken  from  Leino  [37].  In  general,  a  quantification  is  {op  boundvars  |  ranges  >  expression), 
where  op  is  the  operator  of  the  quantification,  boundvars  is  the  set  of  bound  variables,  ranges 
is  a  predicate  restricting  the  ranges  of  the  bound  variables,  and  expression  is  the  expres¬ 
sion  to  be  quantified.  The  operator  of  the  quantifier  must  be  associative  and  commutative, 
and  must  have  an  identity  element.  A  variable  with  no  range  specification  is  quantified  over 
the  entire  range  of  its  type;  if  there  are  no  range  specifications  in  the  quantifier,  the  shorter 
{op  boundvars  >  expression)  form  can  be  used.  If  an  empty  range  is  specified  (there  are  no 
values  for  the  bound  variables  which  satisfy  the  range  predicate),  the  value  of  the  quantifier  is 
the  identity  element  of  op. 
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Example  3.1  (Quantifications) 

1.  Universal:  (Vi|0<i<lV[>  a[i]  =  0)  holds  if  every  element  of  array  a  with  an  index 
between  0  and  N  inclusive  equals  0,  and  does  not  hold  otherwise.  If  the  range  of  a  univer¬ 
sal  quantification  is  empty,  the  quantification  holds.  By  convention,  we  use  the  V  symbol 
instead  of  the  A  operator  in  universal  quantifications. 

2.  Existential:  <3 i  |  0  <  i  <  N  >  a[i]  =  0)  holds  if  there  is  at  least  one  element  of  array  a 
with  an  index  between  0  and  N  inclusive  that  equals  0,  and  does  not  hold  otherwise.  If 
the  range  of  an  existential  quantification  is  empty,  the  quantification  does  not  hold.  By 
convention,  we  use  the  3  symbol  instead  of  the  v  operator  in  existential  quantifications. 

3.  Summation:  (Si  |  0  <  i  <  N  >  a[i])  evaluates  to  the  sum  of  all  elements  of  array  a  with 
indices  between  0  and  N  inclusive.  If  the  range  of  a  summation  is  empty,  the  summa¬ 
tion  evaluates  to  0.  By  convention,  we  use  the  S  symbol  instead  of  the  +  operator  in 
summations. 

The  everywhere  operator,  denoted  by  enclosing  a  predicate  in  square  brackets  ([]),  is  a  spe¬ 
cial  instance  of  quantification.  Introduced  by  Dijkstra  and  Scholten  [17]  as  a  function  from 
predicates  to  Boolean  values,  it  is  an  implicit  universal  quantification  of  the  enclosed  predicate 
over  all  states.  We  use  the  everywhere  operator  in  some  of  the  definitions  and  theorems  of  this 
chapter. 

3.1.2  Assertions 

In  Eloare  logic  [25,  26],  the  assertion  {p}  s  {q}  (usually  referred  to  as  a  Hoare  triple)  denotes 
that  execution  of  statement  s  in  any  state  that  satisfies  predicate  p  either  terminates  in  a  state 
that  satisfies  predicate  q  or  does  not  terminate.  We  use  a  similar  construct  to  make  statements 
about  the  execution  of  Dynamic  UNITY  transitions:  if  the  assertion  {p}  g  — -  t  {q}  holds,  it 
means  that  the  execution  of  transition  g  — -tin  any  state  that  satisfies  p  either  terminates  in 
a  state  that  satisfies  q  or  does  not  terminate.  Since  all  well-formed  Dynamic  UNITY  transitions 
terminate  (by  definition),  we  will  avoid  the  issue  of  nonterminating  computations  by  assuming 
for  the  remainder  of  this  discussion  that  all  transitions  are  well-formed. 

The  execution  of  the  transition  g  — -  t,  as  discussed  previously,  either  establishes  t  (if 
g  holds)  or  is  equivalent  to  skip  (if  g  doesn’t  hold).  Thus,  our  g  — -  t  is  equivalent  to  the 
if  B  — -  5  Q-'B  — -  skip  fi  conditional  described  by  Dijkstra  and  Scholten  [17]  and  by  Morgan 
[52],  where  B  is  the  guard  g  and  5  is  a  statement  that  establishes  the  binary  predicate  t  on  the 
pre-  and  post-states. 

We  now  formally  define  the  semantics  of  a  Dynamic  UNITY  transition.  In  these  definitions, 
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suppose  5  is  a  statement  that  establishes  the  binary  predicate  t  on  the  pre-  and  post-states.  In 
terms  of  Hoare  triples,  a  transition  is  defined  as  follows: 

{p}  g  —  t  {q}  =  {p  A  g}  S  {q}  A  {p  A  -<g}  skip  {q}  (3.1) 

In  terms  of  weakest  preconditions,  a  transition  is  dehned  as  follows  (instantiating  the  Dijk- 
stra/Scholten  dehnition  of  if  ): 

[wp.ig  — *  t).X  =  (g  =>  wp.S.X)  A  {->g  =>  wp.skip.X )]  (3.2) 

Thus,  in  order  to  prove  {p}  g  — <  t  \q] ,  we  must  show  the  following  (where  q'  is  q  with  all 
its  free  variables  primed;  that  is,  q  in  the  post-state): 

(p  /\g  A  t  =>  q')  a  (p  a  ->g  =>  q)  (3.3) 

Assertions  may  be  quantified  using  any  quantifier  that  operates  on  the  Boolean  values.  We 
sometimes  write  assertions  as  {p}  s  { q { ,  where  s  is  known  to  be  a  Dynamic  UNITY  transition 
(as  in  a  quantification  over  the  minimal  set  of  transitions  in  a  running  process).  The  context 
will  always  eliminate  any  possible  confusion  between  one  of  our  assertions  and  a  traditional 
Hoare  triple. 

3.1.3  Functions  and  Operators 

We  use  all  the  usual  mathematical  and  logical  operators,  as  well  as  some  temporal  operators  that 
will  be  dehned  later  in  this  chapter.  We  denote  function  application,  including  the  application 
of  unary  operators  on  predicates  (such  as  transient),  with  the  operator.  We  also  denote 
operation  invocation  and  access  to  data  structures  with  the  operator,  but  the  usage  of  the 
operator  is  always  clear  from  context.  Function  application  always  associates  to  the  left.  We 
adopt  the  following  conventions  regarding  the  precedence  of  logical  relations.  All  relations 
in  each  group  have  the  same  precedence,  and  the  groups  are  listed  in  order  of  increasing 
precedence: 

1.  follows  ,  (leads-to),  next 

2.  = 

3.  =>,  <= 

4.  A,  V 

5.  =,  ± 
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6.  mathematical  operators,  with  their  usual  binding  powers 

7.  - 

8.  .  (function  application,  operation  execution),  1/  (filtering  operator),  XI  (concatenation  op¬ 
erator) 

For  any  two  predicates  p  and  q,  p  =  q  and  p  =  q  have  identical  meanings.  However, 
since  the  precedences  of  =  and  =  differ,  we  can  unambiguously  write  expressions  such  as 
p  =  r  =  q  =  s.  Note  that  the  =  operator  is  only  defined  on  predicates,  while  the  =  operator  is 
defined  on  everything. 

The  filtering  operator  (H),  where  k  is  a  bound  variable  of  the  operator,  is  used  primarily  to 
examine  subsequences  of  message  histories  but  can  also  be  used  for  other  purposes.  It  is  a 
binary  operator  taking  a  set,  sequence  or  array  as  its  first  operand  and  a  predicate  as  its  second; 
it  applies  the  predicate  to  every  element  in  the  first  operand  (denoted  by  k  in  the  predicate)  and 
returns  a  set,  sequence,  or  array  (respectively)  containing  only  the  elements  of  the  first  operand 
that  satisfy  the  predicate  with  their  ordering  (if  any)  preserved.  For  example,  if  x  is  the  integer 
sequence  (1, 1,  2,  3, 1,4,  5,  7),  then  x  ifc  (k  >  1)  evaluates  to  the  sequence  (2,  3, 4,  5,  7). 

The  concatenation  operator  (X)  is  used  to  generate  sequences  from  other  sequences  or 
elements.  It  takes  two  operands,  each  a  sequence  or  an  element,  and  returns  the  sequence 
generated  by  concatenating  them.  For  example,  if  x  is  the  integer  3,  and  y  is  the  integer 
sequence  (4,  5, 6 ),x\Ay  evaluates  to  the  sequence  (3,4,  5,  6). 

3.2  Formal  Execution  Model 

In  this  section,  we  formalize  the  execution  model  described  in  Section  2.3.1.  We  first  formalize 
the  execution  model  for  programs,  and  then  the  execution  model  for  systems.  These  models  are 
constructed  in  such  a  way  that  it  is  possible  to  prove  properties  of  Dynamic  UNITY  programs 
that  remain  applicable  when  those  programs  are  incorporated  into  larger  systems.  This  forms 
the  basis  for  reasoning  about  multiple  communicating  processes  in  Dynamic  UNITY. 

3.2.1  Program  Executions 

Each  execution  of  a  Dynamic  UNITY  program  P  is  an  infinite  sequence  of  pairs  (Si,  T{)  for  i  >  0, 
where  Si  is  the  execution  state  at  step  i  and  T,  is  the  transition  of  P  to  be  executed  at  step 
i.  Every  nontrivial  program  has  an  infinite  number  of  possible  executions.  We  denote  the  set 
containing  all  possible  executions  of  a  particular  program  P  by  P.X,  and  the  subset  of  P.X 
containing  only  executions  where  the  program’s  instantiation  parameters  satisfy  a  predicate  p 
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by  P.X(p).  There  is  a  special  execution  state,  called  the  uninitialized  state  and  denoted  by  11, 
which  holds  before  the  initialization  of  the  execution  state,  and  a  special  transition,  denoted 
by  initialize,  which  takes  the  system  from  the  uninitialized  state  to  an  initial  state. 

The  strongest  predicate  that  holds  on  a  state  5— that  is,  the  predicate  that  completely  spec¬ 
ifies  the  values  of  all  variables  in  the  state  5— is  denoted  by  Pred(S).  1)  may  be  skip,  since 
all  programs  implicitly  contain  skip  as  a  transition.  We  sometimes  denote  T,  explicitly  as  a 
guarded  transition  g,  — »  £j. 

The  transition  set  of  a  Dynamic  UNITY  program  changes  with  the  execution  state,  due  to 
the  existence  of  quantified  transitions.  Given  a  complete  specification  of  a  program’s  state,  it 
is  always  possible  to  determine  the  exact  transition  set  for  the  program  from  the  program  text. 
However,  in  order  to  prove  program  properties,  we  will  often  need  to  determine  the  transition 
set  using  an  incomplete  specification  of  the  program  state.  Given  any  predicate  constraining 
the  program  state,  we  define  minimal  and  maximal  transition  sets  as  follows. 

Definition  3.1  (Minimal  Transition  Set)  The  minimal  transition  set  of  a  program  P  con¬ 
strained  by  a  predicate  p  contains  exactly  those  fair  transitions  of  P  that  exist  in  all  program 
states  S  for  which  Pred(S)  =>  p.  That  is,  the  minimal  transition  set  is  the  intersection  of  the  fair 
transition  sets  for  all  program  states  satisfying  p.  We  denote  the  minimal  transition  set  of  P 
constrained  byp  as  P.rT~(p). 

Definition  3.2  (Maximal  Transition  Set)  The  maximal  transition  set  of  a  program  P  con¬ 
strained  by  a  predicate  p  contains  exactly  those  (fair  and  unfair)  transitions  of  P  that  exist  in 
any  program  state  S  for  which  Pred(S)  =>  p.  That  is,  the  maximal  transition  set  is  the  union  of 
the  transition  sets  for  all  program  states  satisfying  p.  We  denote  the  maximal  transition  set  of  P 
constrained  byp  asP.T+( p). 

We  sometimes  denote  the  transition  sets  of  a  particular  program  execution  using  that  execu¬ 
tion’s  label  instead  of  its  program’s;  i.e.,  R.T~(p)  instead  of  P.T~(p),  where  R  is  an  execution 
of  P. 

Example  3.2  (Transition  sets) 

The  minimal  and  maximal  transition  sets  of  a  simple  Dynamic  UNITY  program  (Specification 
3.1)  constrained  by  various  predicates  are  listed  in  Table  3.1.  We  denote  instances  of  transition 
(2)  with  i  =  k  by  2fc. 

Every  program  execution  state  contains  the  outbox  state  for  the  single  outbox  of  the  execu¬ 
tion,  the  inbox  state  for  every  inbox  created  up  to  that  point  in  the  execution,  and  the  values 
of  the  conventional  state  variables  of  the  program.  We  denote  the  outbox  state  at  step  i  by 
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program  ExampleProgram 

declare 

theSet:  set  {integer} 

initially 

theSet  =  0 

fair-transition 

(1)  true  — ►  <3  i  |  i  £  theSet  >  theSet'  =  theSet  u  {i}) 

(2)  0  { 0  i  I  i  £=  theSet  i>  i  >  1138  — •  p:  p'  =  new  ExampleSystemComponent) 

unfair-transition 

(3)  true  — *  theSet'  =  0 


end 


Specification  3.1:  An  example  program  used  to  illustrate  minimal  and  maximal  transition  sets 


p 

ExampleProgram.T"  (p) 

ExampleProgram.  T' + (p) 

true 

theSet  =  0 

(Vi  |  i  e  theSet  >  0  <  i  <  3) 
{11,21}  <=  theSet 
theSet  =  {1,27,36} 

{1} 

{1} 

{1} 

{1,  2n,  221} 

{  1 .  2l,  227,  236} 

{1, 2o,  2_i,  2i,  2_2,  22, . . . ,  3} 
{1,3} 

{1,20,2i,22,  23,  3} 

{ 1, 2o,  2_i ,  2i,  2_2,  22, . . . ,  3} 
{1,  2i,  227,  236,  3} 

Table  3.1:  Transition  sets  corresponding  to  various  predicates  on  the  state  of  the  program  in 
Specification  3.1. 

Of,  the  outbox  state  as  a  variable  (for  use  in  theorems  and  proofs)  by  (9,  the  set  containing  the 
names  of  all  inboxes  existing  at  step  i  by  lt,  the  state  of  the  inbox  with  name  k  at  step  i  by  If, 
and  the  inbox  with  name  k  as  a  variable  (for  the  purpose  of  quantifying  over  inbox  variables  in 
theorems  and  proofs)  by  lk.  Every  execution  state  Si  consists  of  a  volatile  and  a  non-volatile 
portion,  which  are  defined  as  follows. 

Definition  3.3  (Volatile  and  Non-volatile  State)  The  volatile  portion  of  an  execution 
state  Si  consists  of  the  sent  fields  for  the  messages  in  Of  and  2^  .history  (the  sequence  of  messages 
which  have  been  delivered  to  inbox  k)  for  all  inboxes  k  in  If.  The  non-volatile  portion  of  an 
execution  state  Si  consists  of  everything  else  in  Si. 

The  volatile  portion  of  an  execution  state  can  only  be  modified  by  the  messaging  system, 
while  the  non-volatile  portion  can  only  be  modified  by  program  transitions.  The  volatile  and 
non-volatile  portions  of  the  state  are  non-intersecting,  and  are  denoted  (respectively)  by  ” V.Si 
and  ’V.St. 

An  individual  program  execution  is  also  called  a  process.  Every  process  has  a  globally  unique 
label  associated  with  it;  when  referring  to  the  states  and  transitions  of  the  process  with  label 
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/,  we  use  a  superscript  /  (as  in  Sj,  T-)  to  denote  the  process  we  are  referring  to.  Processes  are 
subject  to  certain  safety  and  progress  constraints,  which  we  describe  in  the  following  sections. 

3 .2 . 1 . 1  Safety  Constraints 

The  following  constraints  on  processes  are  safety  constraints.  They  restrict  the  possible  states 
and  transitions  for  each  step  of  an  execution.  We  denote  the  globally  unique  label  of  the  process 
under  discussion  by  L. 

Initial  Step  Every  execution  has  an  initial  step,  hereafter  denoted  by  I,  such  that  I  is  the  earliest 
step  for  which  the  execution  state  is  not  uninitialized  (recall  that  the  uninitialized  state  is 
denoted  by  11). 

I  =  (mini  |  0  <  it>St  +  11)  (3.4) 

Pre-Initial  Transitions  The  transition  at  the  execution  step  before  the  initial  step  is  initialize, 
and  the  transition  at  every  step  before  the  initialize  transition  is  skip.  Note  that  if  the  initial 
step  is  step  0,  the  initialize  transition  implicitly  occurs  before  step  0  (at  “step  -1”). 

Ti-i  =  initialize  A(Vi|0<i</-l[>Tj  =  skip)  (3.5) 

Initial  State  The  initial  state,  Si,  is  specified  by  the  parameters  and  the  initially-section  of  the 
program.  This  state  need  not  be  the  same  for  all  executions,  since  there  may  be  variation 
in  the  initializations  of  variables  due  to  differing  program  parameters  or  nondeterministic 
initializations. 

Transitions  and  Subsequent  States  Each  transition  7),  i  >  I,  is  chosen  from  the  maximal  tran¬ 
sition  set  corresponding  to  Si  (Equation  3.6),  and  the  change  in  the  nonvolatile  state  between 
Si  and  Si+\  results  from  the  execution  of  transition  T,  (Equation  3.7): 

(Vi  |/<  ii>Ti  Gk.r+(Pred(5i)))  (3.6) 

(Vi  |  I  <  i  >  {Pred(V.Si)}  gt  — ■  U  {Predt'V.Sj+i)})  (3.7) 


Messaging  Safety  The  set  of  inboxes  in  the  execution  is  monotonically  nondecreasing  (Equa¬ 
tion  3.8);  for  every  inbox,  the  message  sequence  and  the  index  of  the  current  message  are  mono¬ 
tonically  nondecreasing  (Equation  3.9);  the  message  sequence  and  message  delivery  states  in 
the  outbox  are  monotonically  nondecreasing  (Equation  3.10);  and  for  every  inbox  in  the  execu¬ 
tion  state  at  a  particular  execution  step,  the  sequence  of  messages  in  that  inbox  from  process 


36 


L  is  the  same  as  the  sequence  of  delivered  messages  in  process  L’s  outbox  addressed  to  that 
inbox  (Equation  3.11).  We  denote  the  sequence  consisting  of  only  the  msg  fields  of  the  elements 
of  sequence  history  by  history.msg.  For  inboxes  i,  j,  the  equation  i  <  j  means  that  the  name 
attributes  of  i  and  j  are  equal,  the  cnt  and  len  attributes  of  i  are  less  than  or  equal  to  the 
corresponding  attributes  of  j,  and  the  sequences  of  msg  and  proc  fields  in  i  are  subsequences 
of  the  corresponding  sequences  in  j.  For  outboxes  i,  j,  the  equation  i  <  j  means  that  the  len 
attribute  of  i  is  less  than  or  equal  to  the  len  attribute  of  j,  that  the  sequences  of  msg,  proc 
and  mbox  fields  in  i  are  initial  subsequences  of  the  corresponding  sequences  in  j,  and  that  for 
every  del  held  of  i  which  has  the  value  true,  the  del  held  of  j  also  has  the  value  true. 


<Vi  |0^i>licji+1) 

<Vi,fc|0=£iAfceIi>I?  <lf+1) 

( Vi  |  0  <  i  >  <9j  <  Oi+1 ) 

(Vi,  b  |  0  <  i  A  b  e  1{  >  (if  iOT(ra.proc  =  L)).msg  = 

Of  lm  (ra.del  A  ra.proc  =  L  A  ra.mbox  =  b).msg) 


(3.8) 

(3.9) 

(3.10) 

(3.11) 


Termination  If  there  exists  an  i,  0  <  i,  such  that  T,  contains  a  stop  command  that  is  executed, 
then  for  all  j  >  U  Tj  =  skip.  That  is,  once  a  stop  command  is  executed,  the  nonvolatile  state 
of  the  process  stops  changing. 


3.2. 1.2  Progress  Constraints 

The  following  constraints  on  program  executions  are  progress  constraints.  They  ensure  that 
weak  fairness  is  guaranteed  for  transition  executions  and  that  all  sent  messages  are  eventually 
delivered. 


Weak  Fairness  As  dehned  in  Chapter  2,  weak  fairness  means  that  every  fair  transition  is 
inhnitely  often  either  selected  or  not  available  for  execution.  This  is  equivalent  to  saying  that 
if  a  transition  is  available  for  execution  at  every  step  after  a  certain  step  k,  and  is  guaranteed 
to  remain  in  the  transition  set  at  least  until  it  is  executed,  then  the  transition  is  executed  at 
some  step  after  k.  This  is  expressed  by  the  following  equation. 


( V  5 ,  k  |  k  >  0  A  5  e  P.T'-(Sk)  >  (3  j  \j>kt>  (Tj  =  s)  v  (s  £  P.T'-(Sj)))) 


(3.12) 


37 


Message  Delivery  In  order  to  reason  about  message  communication,  we  need  the  constraint 
that  all  sent  messages  are  eventually  delivered  to  their  destinations.  Within  the  process  labelled 
L,  this  is  expressed  by  the  following  equation. 

( Vi,  b,  k  |  i  >  0  a  b  e  a  k  <  {Ot  \m  (m.proc  =  I  a  ra.mbox  =  b)).msg  \> 

( 3j  \  j  >  i\>k  <  ( lj  lm  (ra.proc  =  I)).msg))  (3.13) 


3.2.2  System  Executions 

Each  execution  of  a  Dynamic  UNITY  system  consists  of  an  infinite  sequence  of  tuples  (Si,  T/, 
Li,  Zi),  where  Si  is  the  execution  state  of  the  system  at  step  i,  T\  is  the  transition  of  X  to  be 
executed  at  step  i,  Li  is  a  set  containing  the  labels  of  all  running  processes  in  the  system  at  step 
i,  and  Z,  is  a  set  containing  the  labels  of  all  stopped  processes  in  the  system  at  step  i.  As  in 
program  executions,  T,  may  be  skip.  Every  nontrivial  system  has  an  infinite  number  of  possible 
executions;  we  denote  the  set  containing  all  possible  executions  for  a  particular  system  X  by 
Y.X. 

We  use  notation  similar  to  that  for  program  executions  (for  example,  the  maximal  transition 
set  for  a  system  X  constrained  by  a  predicate  p  is  X.'T+(p)).  In  particular,  to  denote  the  set 
containing  the  (process-qualified)  names  of  all  inboxes  in  the  system  at  step  i  we  write  2t,  to 
denote  the  set  containing  the  names  of  all  inboxes  belonging  to  a  particular  process  /  at  step  i 
we  write  l\,  to  explicitly  denote  the  inbox  named  “in”  belonging  to  a  particular  process  /  at  step 
i  we  write  J-  m,  to  denote  the  inbox  named  “in”  belonging  to  a  particular  process  /  as  a  variable 
we  write  2!  in,  to  denote  the  outbox  state  of  process  /  at  step  i  we  write  0\,  and  to  denote  the 
outbox  state  of  process  /  as  a  variable  we  write  Ol.  System  executions  are  subject  to  certain 
safety  and  progress  constraints,  which  we  describe  in  the  following  sections. 

3.2.2. 1  Safety  Constraints 

The  following  constraints  on  system  executions  are  safety  constraints.  They  restrict  the  possi¬ 
ble  states  and  transitions  for  each  step  of  an  execution. 

Initial  Processes  The  set  of  running  processes  at  the  initial  step,  lo,  consists  of  an  instanti¬ 
ation  of  the  system’s  initial  program  and  any  processes  created  as  a  result  of  that  program’s 
initialization;  these  are  called  the  initial  processes.  The  set  of  stopped  processes  at  the  initial 
step,  Zo,  is  empty  because  it  is  not  possible  for  any  process  to  execute  a  stop  statement  before 
the  initial  step. 
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Initial  State  The  initial  state,  So,  is  specified  by  the  parameters  and  the  initially-section  of  the 
system’s  initial  program  and  any  processes  created  as  a  result  of  that  program's  initialization. 
This  state  need  not  be  the  same  for  all  executions,  since  there  may  be  variation  in  the  initial¬ 
ization  of  variables  due  to  differing  program  parameters  or  nondeterministic  initializations. 

Transitions  and  Subsequent  States  Each  transition  T),  i  >  0,  is  chosen  from  the  transition 
set  corresponding  to  Si  (Equation  3.14),  and  the  change  in  the  nonvolatile  state  between  5/  and 
Si+ 1  results  from  the  execution  of  transition  T,  (Equation  3.15): 

(Vi  |  0  <  it>Ti  eX.T(SO)  (3.14) 

(Vi  |  0  <  i  >  {T.Si}  gt  —  U  {T.Si+i})  (3.15) 

Process  Set  Monotonicity  The  set  of  processes  (both  running  and  stopped)  in  the  system 

is  monotonically  nondecreasing  (Equation  3.16);  the  set  of  stopped  processes  in  the  system 

is  monotonically  nondecreasing  (Equation  3.17);  the  intersection  of  the  sets  of  running  and 

stopped  processes  is  empty  (Equation  3.18). 


( Vi  |  0  <  i  >  [U  u  Zi  c  Li+1  u  Zi+ 1)>  (3.16) 

(Vi  |  0<  i>Zt  <=  zi+l)  (3.17) 

(Vi  |  0  <  i\>U  n  Z,  =  0)  (3.18) 

System  State  and  Process  States  The  system  state  at  every  execution  step  is  the  Cartesian 
product  of  the  states  of  the  processes  in  the  system  at  that  step. 

(Vi  |  0  <  it>Si  =  (xf  |  lsLi>Sl))  (3.19) 

Execution  Noninterference  Every  execution  step  of  the  system  can  be  expressed  as  an  execu¬ 
tion  step  of  one  running  process  in  the  system  (Equations  3.20,  3.21).  If  one  running  process 
has  a  non-skip  transition,  it  is  executed  and  the  nonvolatile  portion  of  that  process’s  state  is 
changed,  while  the  nonvolatile  portions  of  other  processes’  states  are  not  changed  (Equation 
3.22). 


(Vi  |  0  <  i  >  (31  |  l  e  Li  >  Ti  =  T\)  a  (VI  |  l  e  U  A  Tt  +  T\  d>  T\  =  skip))  (3.20) 

(Vi,  l  |  0  <  i  A  l  e  Li  A  Ti  =  T\  >  \y.SLL}  gt  —  U  {y.Sli+1})  (3.21) 

( Vi,  /  |  0  <  i  A  l  G  Li  A  Ti  +  T\  >  y.s[  =  y.Sli+1) 


(3.22) 
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Process  Set  Determinism  For  all  i,  0  <  i,  if  process  l  is  in  L/+i  and  not  in  Li,  then  process  / 
must  be  created  as  a  result  of  transition  T,.  For  all  i,  0  <  i,  if  process  1  is  stopped  at  step  i  +  1, 
i.e.,  1  is  in  Zj+i,  then  either  (a)  process  1  was  already  stopped  at  step  i  (1  is  in  Z,,  and  T ■  is  skip)  or 
(b)  process  l  stops  at  step  i  (l  is  in  L,  and  T[  contains  a  stop).  That  is,  processes  cannot  appear 
in  the  system  after  the  initial  step  without  having  been  created  by  other  processes  and  cannot 
be  stopped  except  by  transitions  of  their  own,  and  stopped  processes  can  have  no  non-skip 
transitions.  Therefore,  stopped  processes  cannot  re-enter  the  system. 

Messaging  Safety  The  messaging  safety  rules  specified  for  processes  in  Equations  3.8-3.11 
hold  for  systems  as  well.  In  addition,  for  every  inbox  and  process  in  the  execution  state  at  a 
particular  execution  step,  the  sequence  of  messages  in  that  inbox  delivered  from  that  process 
is  the  same  as  the  sequence  of  delivered  messages  in  that  process’s  outbox  addressed  to  that 
inbox. 

(Vp,  q,  i,  b  |  p  e  L,  u  Z;  a  q  e  I,  u  Z*  a  0  <  i  a  b  <=  ?f+1l> 

(lf+i  1  m  (m.proc  =  p)).msg  =  (Of  lm  (m.del  A  m.proc  =  q  a  ra.mbox  =  b)).msg)  (3.23) 

3.2.2.2  Progress  Constraints 

The  following  constraints  on  system  executions  are  progress  constraints.  They  ensure  that 
weak  fairness  is  guaranteed  for  transition  executions  and  that  all  sent  messages  are  eventually 
delivered. 

Weak  Fairness  If  a  transition  is  available  for  execution  at  every  step  after  a  certain  step  k  and 
is  guaranteed  to  remain  in  the  transition  set  at  least  until  it  is  executed,  then  the  transition  is 
executed  at  some  step  after  k.  This  is  expressed  by  the  following  equation. 

(Vs,  k  |  k  >  0  a  5  e  X.T~(Sk)  >  |  j  >  k>Tj  =  rwr^X.T~(Sj)))  (3.24) 


Message  Delivery  In  order  to  reason  about  message  communication,  we  need  the  constraint 
that  all  sent  messages  are  eventually  delivered  to  their  destinations.  Within  a  system  execution, 
this  is  expressed  by  the  following  equation. 

{\/p,q,i,b,k  |  p  g  If  u  Zj  A  q  e  If  u  Z,  A  0  <  i  a  b  e  if  A 

k<  «9f  i  m  (  m.proc  =  q  A  m.mbox  =  fc)).msg  c> 

{3j  |  j  >  i>  k  <  ( lj'b  \m  (m.proc  =  L)).msg>)  (3.25) 
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3.2.3  Subsystem  Executions 

A  subsystem  consists  of  a  fixed  subset  of  the  processes  of  a  system.  A  subsystem  execution  is 
the  projection  of  a  system  execution  which  contains  the  states  and  transitions  of  the  processes 
in  the  subsystem.  Subsystem  executions  have  the  same  form  as  system  executions— infinite 
sequences  of  tuples  (Sj' ,  T J ,  L\ ,  Z\ ),  where  V  is  the  set  of  processes  in  the  subsystem.  The  tu¬ 
ples  which  make  up  a  subsystem  execution  are  computed  from  the  tuples  of  the  corresponding 
system  execution  as  follows: 

•  For  all  i  >  0,  5tv  =  <x/  |  I  e  V  A  /  e  U  u  Z,  >  S\). 

■  For  every  transition  T,  such  that  T,  =  T\,  l  e  V,  T'  =  7j .  For  all  other  transitions  T;, 

T]  =  skip. 

•  For  all  i>  0,  Lj  =  U  n  V  and  Z\  =  Z,  n  V. 

All  our  reasoning  will  be  done  on  subsystems.  We  use  notation  for  subsystems  analogous 
to  that  for  systems  (so  that,  for  example,  the  maximal  transition  set  of  a  subsystem  V  con¬ 
strained  by  predicate  p  is  V.T+(p)).  Typically,  V  will  consist  of  either  a  single  process  /  (and 
the  subsystem  will  be  the  process  l  in  isolation)  or  the  entire  set  of  processes  for  a  system  (and 
the  subsystem  will  be  the  entire  system).  The  benefit  of  this  approach  is  that  if  we  can  prove 
properties  about  all  executions  of  a  particular  program,  these  properties  hold  for  all  systems 
containing  any  execution  of  that  program.  We  use  the  execution  model  to  formalize  our  op¬ 
erational  understanding  of  Dynamic  UNITY  executions.  However,  when  proving  properties  of 
programs  and  systems,  we  try  to  use  assertions  rather  than  directly  reasoning  about  subsystem 
execution  sequences. 

3.3  Fundamental  Operators 

In  this  section,  we  define  the  three  fundamental  operators  initially,  next  and  transient  in  terms 
of  our  execution  model,  and  present  proof  rules  for  using  them  in  our  logical  framework.  In 
subsequent  sections,  we  will  use  these  fundamental  operators  to  define  other  useful  operators 
(stable,  invariant,  (leads-to),  follows).  These  operators  will  form  the  basis  for  reasoning 
about  our  programs  and  systems.  When  these  operators  are  used  in  proofs,  the  systems  to 
which  they  apply  will  generally  be  understood  from  context.  However,  we  explicitly  specify 
them  in  the  definitions  and  theorems  of  this  chapter. 
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3.3.1  Initially 

The  initially  operator  allows  us  to  formalize  initial  conditions  for  the  execution  of  a  subsystem. 
It  is  defined  as  follows: 

Definition  3.4  (Initially  Operator)  Given  predicate  p  and  subsystem  X:  initially.p.X  holds 
if,  for  every  possible  execution  ofX,  p  holds  in  the  initial  state. 

initially.p.X  =  (VY  |  Y  G  X.X  >  [Pred(Y.So)  =>  p]) 

initially.p.X  can  be  proven  from  the  program  texts  which  comprise  subsystem  X,  because 
the  initial  condition  of  the  system  can  be  calculated  directly  from  the  texts  of  the  declare  and 
initially  sections  of  the  programs  and  the  parameters  passed  to  the  initial  programs. 

3.3.2  Next 

The  next  operator  allows  us  to  prove  safety  properties  of  a  subsystem,  by  specifying  restric¬ 
tions  on  the  next  subsystem  state  given  the  current  subsystem  state.  It  is  defined  as  follows: 

Definition  3.5  (Next  Operator)  Given  predicates  p  and  q  and  subsystem  X:  (p  next  q).X 
holds  if  for  every  execution  ofX,  every  state  in  which  p  holds  is  immediately  followed  by  a  state 
in  which  q  holds. 

{p  next  q).X  =  (V  Y,  i  \  Y  e  X.X  a  i  >  0  >  [Pred(Y.Si)  =>  p]  =>  [Pred(  Y.S/+i)  =>  q]) 


Since  stuttering  steps  are  allowed  in  our  execution  model,  this  definition  constrains  p  and 
q  such  that: 

(p  next  q).X  =>  [p  =>  q]  (3.26) 

Calculating  (p  next  q).X  by  directly  using  this  definition  is  impractical,  since  it  requires 
us  to  verify  an  infinite  number  of  implications  for  an  infinite  number  of  execution  sequences. 
However,  we  can  use  the  knowledge  that  Dynamic  UNITY  systems  instantiate  their  processes 
from  a  static  set  of  programs  and  that  the  non-volatile  state  of  a  process  can  be  manipulated 
only  by  that  process’s  transitions  to  calculate  stronger  properties  that  imply  (p  next  q).X.  The 
following  are  the  resulting  proof  rules. 

Proof  Rule  1  (Next  Property  for  a  Set  of  Processes) 

Given  predicates  p  and  q  over  the  non-volatile  state  of  a  set  ofprocessesX  in  subsystem  X:  if  every 
transition  in  the  maximal  transition  set  ofX  constrained  by  p  terminates  in  a  state  satisfying  q 
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when  executed  in  a  state  satisfying  p,  then  (p  next  q).X  holds. 

(\/s  |  5  e  V.T+(p)  >  {p}  s  {q}) 

(p  next  q).X 

This  proof  rule  is  consistent  with  the  definition  of  the  next  operator,  because  any  transition 
of  the  system  other  than  those  in  V.'T+(p)  has  an  effect  on  V’s  non-volatile  state  equivalent 
to  skip.  We  quantify  over  the  maximal  transition  set  to  ensure  that  we  take  into  account  all 
transitions  that  can  possibly  be  enabled  when  p  holds.  We  can  use  this  rule  to  prove  next 
properties  for  a  single  process  R,  by  making  V  the  set  containing  only  process  R. 

If  p  and  q  are  predicates  over  volatile  state  (or  a  combination  of  volatile  and  non-volatile 
state),  the  semantics  of  the  messaging  system  must  be  taken  into  account.  This  is  typically 
done  using  the  follows  operator,  discussed  later  in  this  chapter. 

The  next  operator  has  previously  appeared  in  the  context  of  static  systems  in  various  forms, 
including  the  co  operator  in  Misra  [47],  the  next  operator  in  Chandy  and  Sanders  [9,  10],  the 
next  operator  in  Sivilotti  [66],  and  the  O  operator  in  temporal  logic  [62]. 

3.3.3  Transient 

The  transient  operator  allows  us  to  prove  progress  properties  of  a  subsystem,  by  specifying 
that  certain  predicates  on  the  state  of  a  subsystem  cannot  hold  forever. 

Definition  3.6  (Transient  Operator)  Given  predicate  p  and  subsystem  X:  transient.p.X 

holds  if,  for  every  execution  ofX,  every  state  is  followed  by  some  later  state  in  which  -p  holds. 

transient.p.X  =  (V  Y,  i  \  Y  e  X.X  a  i  >  0  >  (3 j  \  j  >  i>  [Pred(T.Sj)  =>  ~^p])) 


Calculating  transient./?  by  directly  using  this  definition  is  impractical,  since  it  requires  us 
to  verify  an  infinite  number  of  implications  for  an  infinite  number  of  execution  sequences. 
However,  we  can  use  the  knowledge  that  Dynamic  UNITY  systems  instantiate  their  processes 
from  a  static  set  of  programs  and  that  the  non-volatile  state  of  a  process  can  be  manipulated 
only  by  that  process’s  transitions  to  calculate  stronger  properties  that  imply  transient.p.X. 
The  following  are  the  resulting  proof  rules. 

Proof  Rule  2  (Transient  Operator  for  a  Set  of  Processes) 

Given  a  predicate  p  over  the  non-volatile  state  of  a  set  of  processes  V  in  subsystem  X:  if  any 
transition  in  the  minimal  transition  set  ofX  constrained  by  p  terminates  in  a  state  satisfying  ->p 
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when  executed  in  a  state  satisfying  p,  then  transient.p.X  holds. 

(35  I  5  £  V.T~{p)  >  {p}  S  P }) 

transient.p.X 

This  proof  rule  is  consistent  with  the  definition  of  the  transient  operator,  because  all  tran¬ 
sitions  in  V.T~(p)  are  guaranteed  to  remain  eligible  for  execution  as  long  as  p  holds.  Weak 
fairness  guarantees  that  if  one  or  more  transitions  in  V.T~{p)  satisfy  the  assertion,  either 
one  such  transition  will  execute  eventually  or  p  will  be  falsified  by  some  transition  outside  of 
V.T~(p).  We  can  use  this  rule  to  prove  transient  properties  for  a  single  process  R,  by  making 
V  the  set  containing  only  process  R. 

If  p  is  a  predicate  over  volatile  state  (or  a  combination  of  volatile  and  non-volatile  state),  the 
semantics  of  the  messaging  system  must  be  taken  into  account. 

The  transient  operator  has  previously  appeared  in  the  context  of  static  systems  in  Misra 
[46]  and  Sivilotti  [66]. 

3.4  Derived  Operators 

In  this  section,  we  define  some  useful  operators  in  terms  of  the  fundamental  operators  defined 
in  the  previous  section. 

3.4.1  Stable 

The  stable  operator  allows  us  to  state  that,  once  a  particular  predicate  on  the  state  of  a  sub¬ 
system  holds,  it  continues  to  hold  thereafter. 

Definition  3.7  (Stable  Operator)  Given  predicate  p  and  subsystem  X:  stable.p.X  holds  if, 
for  every  execution  ofX,  every  state  in  which  p  holds  is  immediately  followed  by  a  state  in  which 
p  holds.  That  is,  p  is  never  falsified  once  it  has  been  established. 

stable.p.X  =  (p  next  p).X 


3.4.2  Invariant 

The  invariant  operator  allows  us  to  state  that  a  particular  predicate  holds  on  every  reachable 
state  of  a  subsystem. 
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Definition  3.8  (Invariant  Operator)  Given  predicate  p  and  subsystem  X:  invariant.p.X 

holds  if,  for  every  execution  ofX,  p  holds  in  every  state. 

invariant.p.X  =  initially. p.X  a  stable. p.X 


3.4.3  Leads-To 


The  (leads-to)  operator  is  the  primary  operator  used  in  progress  proofs.  It  allows  us  to 
show  that  if  a  particular  predicate  on  the  state  of  a  subsystem  holds  at  some  point  during  any 
execution,  another  predicate  is  guaranteed  to  hold  at  some  later  point. 

Definition  3.9  (Leads-to  Operator)  Given  predicates  p  and  q  and  subsystem  X:  (p  q).x 
holds  if  for  every  execution  ofX,  every  state  in  which  p  holds  is  followed  by  some  later  state  in 
which  q  holds.  In  the  third  rule,  S  is  any  set  of  predicates. 


(p  A  -1  q  next  p  v  q).X  transient.(p  A  ~>q).X 
(p  q).X 


(basis) 


(P  qfX  (q  r).X 
(p  r).X 


(transitivity) 


( Vp  |  p  G  S  \>  (p  ^  q) .X) 
(<3p  |  p  G  S  \>  p)  ^  q).X 


(disjunction) 


This  definition  of  the  leads-to  operator  is  due  to  Misra  [46]. 


3.4.4  Follows 

The  follows  operator,  first  described  by  Sivilotti  [66],  combines  safety  and  progress  properties 
and  allows  us  to  show  the  following  relationship  between  two  variables  x  and  y  of  the  same 
partially  ordered  type: 

1.  Both  x  and  y  are  monotonically  increasing. 

2.  The  value  of  x  does  not  exceed  the  value  of  y. 

3.  If  the  value  of  y  exceeds  some  constant  k,  then  the  value  of  x  will  eventually  exceed  k. 

4.  The  difference  between  x  and  y  is  an  upper  bound  on  how  much  x  can  increase  in  one 
subsystem  execution  step. 
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Typically,  the  partial  ordering  on  x  and  y  is  clear  from  context.  We  may  explicitly  denote 
it  by  subscripting  the  follows  operator  with  the  ordering  operator,  as  in  follows<  or  follows^. 

The  follows  operator  for  two  variables  x  and  y  of  the  same  partially  ordered  type  and 
subsystem  X  is  defined  in  terms  of  stable,  ^  and  next  as  follows: 

Definition  3.10  (Follows  Operator) 

(x  follows  y).X  =  ( Vk  >  stable. (x  >  k).X)  a 
(Vk  >  stable. (y  >  k).X)  a 
invariant. (x  <  y).X  a 
( Vk  >  (y  >  k  ^  x  >  k).X)  a 
(\/k\>  (y  =  k  a  x  <  k  next  x  <  k).X) 


3.5  The  Channel  Theorem 

The  channel  theorem  allows  us  to  reason  about  message  channels  using  the  follows  operator, 
by  stating  that  a  follows  relationship  holds  for  every  inbox/process  pair  in  a  system. 

Theorem  3.11  (Channel  Theorem) 

For  all  processes p,  q  in  a  Dynamic  UNITY  system,  and  all  inboxes  b  in  q,  the  sequence  of  messages 
delivered  to  q.b  from  process  p  follows  the  sequence  of  messages  sent  by  process  p  to  q.b: 

{\/p,q,b,i  |  p  e  X.Li  u  X.Zi  A  q  e  X.Li  u  X.Zi  a  b  g  X.l?  > 

UX.l«-b  Im  (m.proc  =  p)).msg  follows 

( X.Op  \m  (m.proc  =  q  A  m.mbox  =  h)).msg).X) 

Proof 

In  order  to  prove  the  channel  theorem,  we  must  use  the  previously  stated  definition  of  the 
messaging  system.  The  parts  of  the  channel  safety  and  progress  properties  from  this  definition 
that  are  relevant  to  the  follows  relationship  in  this  theorem  are  the  following: 

<Vi,h|  0<iAbeli>l?  <IbM)  (a) 


(Vi  |  0  <  i  a  l  e  Lt  u  >  0\<  Oli+1 ) 


(b) 
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( Vp,  q,  i,  b  |  p  e  1/  u  Zi  a  q  e  Li  u  Z,-  a  0  <  i  A  b  e  jf+1  > 

(?■+!  1m  (m.proc  =  p)).msg  :< 

Of  iw  (m.proc  =  q  A  m.mbox  =  fij.msg)  (c) 

{Vp,q,i,b,k  \  p  G  LiU  Zi  A  q  LiU  Zi  A  0  <  i  a  b  <E  1?  A 

k  <  (Of  lTO  (m.proc  =  q  A  m.mbox  =  fo)).msg  r> 

(3j  |  j  >  i  >  k  <  ( lfb  \m  (m.proc  =  I)).msg))  (d) 


And  the  definition  of  x  follows  y  is  the  following: 

(x  follows  y).X  =  (Mk\>  stable. (x  >  k).X)  A  (1) 

(Vfe  >  stable. (y  >  k).X)  A  (2) 

invariant. (x  <  y).X  a  (3) 

( Vk  >  (y  >  k  x  >  k).X)  a  (4) 

( Vk  >  (y  =  k  A  x  <  k  next  x  <  k).X)  (5) 


It  is  immediately  clear  that  conjuncts  (1)  and  (2)  of  the  follows  definition  are  satisfied  by 
channel  properties  (a)  and  (b),  respectively.  Conjunct  (3)  of  the  follows  definition  is  satisfied  by 
channel  properties  (a)  and  (c).  Property  (c)  says  that  the  filtered  X.lf^  is  always  a  subsequence 
of  the  filtered  X.O\’  and  therefore,  because  of  the  monotonicity  from  property  (a),  so  is  the 
filtered  X.lf 'b .  Conjunct  (4)  of  the  follows  definition  is  satisfied  by  channel  property  (d),  which 
says  that  every  sequence  exceeded  by  the  filtered  X.Op  is  eventually  exceeded  by  the  filtered 
X.lq  b.  Finally,  it  is  immediately  clear  from  the  definition  of  next  that  conjunct  (5)  of  the  follows 
definition  is  satisfied  by  channel  property  (c).  Therefore,  the  follows  property  holds.  □ 

3.6  Other  Useful  Theorems 

In  this  section  we  present  some  generally  useful  theorems  about  the  operators  we  have  defined, 
as  well  as  some  theorems  about  the  functioning  of  Dynamic  UNITY  systems.  Some  of  these 
theorems  are  immediately  derivable  from  the  definitions  of  the  fundamental  operators;  we 
therefore  do  not  present  detailed  proofs  for  all  of  them.  In  all  of  the  following  theorems,  p,  q, 
r,  s,  t  are  arbitrary  predicates,  and  X  is  an  arbitrary  system. 
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3.6.1  Theorems  about  Next 

The  following  theorems  about  next  are  due  to  Misra  [47],  and  follow  directly  from  the  definitions 
of  next  and  logical  implication.  Proofs  for  them  will  not  be  presented. 

Theorem  3.12 

Any  predicate  holds  in  all  states  immediately  subsequent  to  states  where  the  predicate  false 
holds: 

(false  next  p).X 


Theorem  3.13 

The  predicate  true  holds  in  all  states  immediately  subsequent  to  states  where  any  predicate  holds: 

(p  next  true)  Jf 

Theorem  3.14  (Conjunction  and  Disjunction) 

The  conjunction  of  any  two  next  properties  gives  additional  next  properties: 

{p  next  q).X  a  (r  next  s).X  =>  (p  A  r  next  q  A  s).X  A  (p  v  r  next  q  v  s).X 

Theorem  3.15  (Strengthening) 

The  left-hand  side  of  any  next  property  can  be  strengthened: 

(p  next  q).X  =>  (p  A  r  next  q).X 


Theorem  3.16  (Weakening) 

The  right-hand  side  of  any  next  property  can  be  weakened: 

(p  next  q).X  =>  (p  next  q  v  r).X 

3.6.2  Theorems  about  Transient 

The  following  are  theorems  about  the  transient  operator,  which  will  be  useful  primarily  for 
proving  theorems  about  the  operator  later  in  this  chapter.  These  theorems  are  due  to  Misra 
[46]. 

Theorem  3.17  (Stability  and  Transience) 

The  only  predicate  that  is  both  stable  and  transient  is  false: 


(stable. p.X  a  transient. p.X)  =  [~>p] 
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Proof 

The  definition  of  transient  tells  us  that  false  is  transient,  and  Theorem  3.12  tells  us  that  false  is 
stable  (because  (false  next  false  ).X  holds).  Therefore,  we  only  need  to  show  that  (stable.  p.X  a 
transient. p.X)  =>  [~^p\.  We  do  this  as  follows: 

From  the  definition  of  transient. p.X,  there  is  some  fair  transition  in  X  such  that  } p  |  g  — * 
t  {-'/?}.  From  the  definition  of  stable. p.X,  {p }  g  — *  t  {p }  for  all  fair  transitions  inX.  Conjoin¬ 
ing  the  postconditions  of  these  two  assertions  gives  {p }  g  — »  t  {false}.  Therefore,  ~<p  must 
hold.  □ 

Theorem  3.18  (Strengthening) 

Any  transient  property  can  be  strengthened: 

transient. p.X  =>  transient. (p  a  q).X 


Proof 

From  the  definition  of  transient.p.X,  there  is  some  fair  transition  in  X  such  that  {p }  g  — - 
t  { — >p} .  We  can  strengthen  the  right  side  and  weaken  the  left  side  of  this  assertion,  to  give 
{P  a  q}  g  — <  t  {— 1  p  v  -i q}.  This  gives  transient.(p  a  q).X  by  definition  of  transient.  □ 

3.6.3  Theorems  about  Leads-to 

The  following  are  theorems  about  the  ^  operator.  They  are  some  of  the  most  important  the¬ 
orems  we  will  use  to  prove  properties  of  Dynamic  UNITY  systems.  These  theorems  are  due  to 
Misra  [46]. 

Theorem  3.19  (Implication) 

Any  implication  is  also  a  property: 

[p  =>  q]  =>  (p  q).X 


Theorem  3.20  (Strengthening) 

The  left-hand  side  of  any  property  can  be  strengthened: 

(P  q).X  =>  (p  A  r  q).X 


Theorem  3.21  (Weakening) 

The  right-hand  side  of  any  property  can  be  weakened: 


( P  q).X  =>  (p  qv  r).X 
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Theorem  3.22  (Disjunction) 

A  universally  quantified  set  of  properties  can  be  transformed  into  a  single  property  with 
existentially  quantified  operands.  In  this  theorem,  p;  and  q;  are  predicates,  and  i  is  quantified 
over  an  arbitrary  set: 


(\/i\>  (Pi  ~~>  qt).X)  =>  ((3i\>  pi)  ^  (3i\>  qi)).X 

Theorem  3.23  (Cancellation) 

Two  properties  of  a  particular  form  can  be  combined,  cancelling  an  intermediate  variable: 

(p  ^  q  v  r).X  A  (r  ^  s).X  (p  ^  q  v  s).X 

Theorem  3.24  (Impossibility) 

A  state  satisfying  false  is  reachable  only  from  an  unreachable  state: 

( V  false). X  =>  [-■  p\ 

Theorem  3.25  (Progress-Safety-Progress) 

Progress  and  safety  properties  of  specific  forms  can  be  combined  to  yield  more  complex  progress 
properties: 

(p  q).X  A  (r  next  s).X  =>  {p  ay  — >  (q  A  r)  v  (—<r  A  s)).X 

B.6.4  Theorems  about  Follows 

The  following  theorems  about  the  follows  operator  are  due  to  Sivilotti  [66].  They  are  extremely 
important  in  proving  relationships  among  communicating  Dynamic  UNITY  processes.  These 
theorems  hold  when  the  ordering  relation  used  to  define  the  follows  operator  defines  a  partially 
ordered  set  on  the  types  of  the  variables. 

Theorem  3.26  (Transitivity) 

The  follows  operator  is  transitive: 

(x  follows  y).X  A  ( y  follows  z).X  =>  (x  follows  z).X 

Theorem  3.27  (Reflexivity) 

If  a  variable  follows  itself,  its  value  never  changes: 


(x  follows  x).X  =  {3k  t>  invariant. (x  =  k).X) 
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Theorem  3.28  (Antisymmetry) 

If  two  variables  follow  each  other,  their  values  are  always  equal: 

(x  follows  y).X  a  (y  follows  x).X  =>  invariant,  (x  =  y).X 

Theorem  3.29  (Monotonicity) 

Application  of  a  monotonic  function  to  both  sides  of  a  follows  property  preserves  the  follows 
property: 


(fis  a  monotonic  function )  A  (x  follows  y  ).X  =>  ( f.x  follows  f.y).X 

Theorem  3.30  (Stable  Fixed  Point) 

An  element  k  is  a  fixed  point  of  function  f  when  k  =  f.k.  We  define  the  set  FP.f  of  fixed  points  for 
a  function  f  as  follows:  FP.f  =  (k  |  k  =  f.k  o  k{ .  If  a  variable  follows  a  monotonic  function  of 
itself,  then  it  never  changes  once  it  reaches  a  fixed  point  of  that  function: 

(x  follows  f.x).X  =>  ( Vk  |  k  G  FP.f  >  stable. (x  =  k).X) 


3.7  Verification  of  an  Example  Program 

In  this  section,  we  present  a  small  example  program  (Specification  3.2)  and  prove  its  correct¬ 
ness  using  the  rules  and  theorems  described  earlier  in  this  chapter.  The  program  implements 
Euclid’s  algorithm  for  calculating  the  greatest  common  divisor  (GCD)  of  two  integers;  it  repeat¬ 
edly  reads  an  integer  message  from  each  of  its  two  inboxes,  performs  Euclid’s  algorithm  on 
these  integers,  and  sends  the  result  to  a  specified  destination  process  and  inbox. 

Let  GCDSeq  be  a  function  that  takes  two  sequences  of  integers  greater  than  or  equal  to  1 
as  input  and  produces  as  output  a  sequence  of  integers,  with  the  same  length  as  the  shorter 
of  the  two  input  sequences,  such  that  each  element  of  the  output  sequence  is  the  GCD  of  the 
corresponding  elements  of  the  two  input  sequences.  The  property  we  wish  to  prove  about 
the  GCD  program  is  O.msg  follows  GCDSeq(x/n.msg,  yin. msg)  (we  use  b.msg  to  denote  the 
sequence  of  messages  on  inbox/outbox  b).  The  proof  relies  on  the  system  constraint  that  all 
messages  sent  to  xln  and  yin  are  positive  integers.  While  we  could  have  added  conditions  to 
the  guards  of  GCDCalculator’s  transitions  to  filter  out  bad  input  messages,  leaving  them  out 
reduces  the  complexity  of  the  example  and  its  proof. 

In  order  to  prove  the  follows  property,  we  must  first  prove  several  other  properties  of 
GCDCalculator.  We  state  these  as  lemmas,  and  prove  some  of  them  in  a  calculational  fashion 
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program  GCDCalculator(targetProcess:  process,  targetlnbox:  string) 

declare 
x,  y:  integer 
xln,  yin:  inbox 
waiting:  boolean 

always 

busy  =  -■  waiting 

initially 

x  =  1  Ay  =  1  a  waiting 

fair-transition 

(1)  xln.probe  A  yln.probe  A  waiting  — * 

x'  =  xln.current.msg  Ay'  =  yln.current.msg  A 
xln.advance  A  yln.advance  a  busy' 

(2)  0  x  <  y  — *  y'  =  y  -  x 

(3)  o  y  <  X  — *  x'  =  x  -  y 

(4)  0  x  =  y  A  busy  — -  send(targetProcess,  targetlnbox,  x)  A  waiting' 

end 


Specification  3.2:  The  GCDCalculator  program 


by  showing  that  they  follow  either  directly  from  the  predicate  true  or  from  our  constraints  on 
the  system.  For  some  lemmas  we  omit  the  calculational  proofs,  as  the  primary  purpose  of  this 
example  is  to  demonstrate  the  proof  techniques  for  our  various  temporal  operators  and  many 
of  the  lemmas  use  the  same  temporal  operators.  We  present  brief  textual  arguments  for  the 
correctness  of  lemmas  for  which  we  omit  calculational  proofs. 

There  is  an  implicit  quantification  over  all  possible  instantiations  of  GCDCalculator  for  each 
property  we  state.  That  is,  our  properties  hold  for  any  instance  of  GCDCalculator  regardless 
of  its  execution  environment  (with  the  system  constraint  that  all  messages  sent  to  its  inboxes 
are  positive  integers).  We  represent  the  GCD  process  within  this  implicit  quantifier  by  G.  In 
addition,  we  will  often  use  a  transition’s  number  instead  of  the  actual  text  of  the  transition 
when  writing  assertions  within  our  proofs. 

Lemma  3.31  (Positive  Integers) 

The  values  of  the  state  variables  x  and  y  are  always  greater  than  or  equal  to  1. 


invariant,  (x  >  1  a  y  >  1) 
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Proof 

invariant,  (x  >  1  A  y  >  1) 

=  {definition  of  invariant  operator} 

initially,  (x  >lAy>l)A(x>lAy>l)  next  (x  >  1  A  y  >  1) 

=  {initially-section  specifies  (x  =  1  A  y  =  1)} 

(x  >  1  a  y  >  1 )  next  (x  >  1  a  y  >  1) 

<=  {proof  rule  for  next  operator} 

(Vs  |  s  £  G.T+(x  >lAy>l)[>{x>lAy>l}5{x>lAy>l}) 

=  {quantification} 

{x>  1aj>  1}  (1)  {x>lAy>l}A{x>lAy>l}  (2)  {x>lAy>l}A 
{x>  1aj>  1}  (3)  {x>lAy>l}A{x>lAy>l}  (4)  {x>lAy>l} 


We  prove  each  conjunct  individually: 

{x>lAy>l}  (1)  {x>lAy>l} 

{definition  of  assertion} 

(x>1aj>1a  ?dn.  probe  A  yhi.probe  a  waiting  ax'  =  x/n.current  a 
y'  =  y/n.current  A  x//i. advance  a  y//i. advance  a  busy'  =>x'>1aj' >1)a 
(x>1aj>1a  -'(x/n.probe  a  y/n.probe  A  waiting )  =>x>  1  Ay  >  1) 

{predicate  calculus:  x  A  y  =>  x} 


x>lAy>lA  xln.  probe  A  yhi.probe  a  waiting  ax’  =  x/n.current  A 
y'  =  y/n.current  a  x/n. advance  a  y/n.advance  A  busy'  =>  x'  >  1  a  y'  >  1 
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<=  {predicate  calculus:  (x  =>  z)  =>  (x  A  y  =>  z)} 

x'  =  a7/i. current  Ay'  =  y//i. current  =>  x'  >  1  a  y'  >  1 
=  {definition  of  current  operation} 

x'  =  x/n[x/n.cnt].msg  Ay'  =  yln[yln. cntj.msg  =>  x'  >  1  A  y'  >  1 
<=  {substitution} 

xln[xln. cntj.msg  >  1  a  y//i[y/n.cnt].msg  >  1 
<=  {definition  of  message  channels} 

system  constraint  that  all  messages  sent  to  ?dn  and  yin  are  positive  integers 

- end  of  {x  >  1  a  y  >  1}  (1)  {x  > 

{x  >  1  a  y  >  1}  (2)  {x  >  1  A  y  >  1} 

=  {definition  of  assertion} 

(x>lAy>lAx<yAy'=y-x^x’>lAy'>l)A 
(x>lAy>lAy<x=>x'  >  1  A  y'  >  1) 

<=  {predicate  calculus:  x  a  y  =>  x} 

x>lAy>lAx<yAy'=y-x=>x'>lAy'>l 

=  \x'  =  x,  since  x'  doesn’t  appear  in  transition  (2)} 

x>lAy>lAx<yAy'=y-x=>x>lAy'>l 

<=  {predicate  calculus:  (x  =>  y  A  z)  =>  (x  =>  y)} 


A  y  >  1} 


x>lAy>lAx<yAy'=y-x^y'>l 
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<=  {substitution} 

x>lAy>lAx<y=>y-x>l 

=  {arithmetic} 

true 

- end  of  {x  >  1  a  y  >  1}  (2)  { x  > 

{x  >  1  a  y  >  1}  (3)  {x  >  l  A  y  >  1} 

<=  {symmetry  with  transition  (2)} 

true 

- end  of  {x  >  1  a  y  >  1}  (3)  {x  > 

{x  >  1  a  y  >  1}  (4)  {x  >  l  A  y  >  1} 

=  {dehnition  of  assertion} 

(x  >  \  ry>\  a  x  =  y  a  busy  A  send(  targetProcess,  targetlnbox,  x)  a  waiting '  => 
x'  >  1  A  y'  >  1)  A 

(x  >  1  a  y  >  1  a  ^(x  =  y  A  busy  a  send} targetProcess,  targetlnbox, x))  => 
x  >  1  A  y  >  1) 

=  {predicate  calculus:  x  a  y  =>  x} 

x>\  a  y  >  \  a  x  =  y  a.  busy  a  send}  targetProcess,  targetlnbox,  x)  A  waiting1  => 
x'  >  1  A  y'  >  1 

<=  {predicate  calculus:  (x  =>  z)  =>  (x  A  y  =>  z )} 
x>lAy>l=>x'>lAy'>l 


A  y  >  1} 


A  y  >  1} 


<=  {x'  =  x  A  y'  =  y ,  since  x'  and  y'  don’t  appear  in  transition  (4)} 
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x>lAy>l=>x>lAy>l 

{predicate  calculus:  x  =>  x} 

true 


- end  of  {x  >  1  a  y  >  1}  (4)  {x  >  1  a  y  >  1} 

Therefore,  the  conjunction  of  all  four  assertions  follows  from  the  predicate  true  and  our 
constraints  on  the  system.  □ 

Lemma  3.32  (Inbox  Synchronization) 

The  number  of  messages  read  from  xln  is  always  the  same  as  the  number  of  messages  read  from 
yin. 

invariant,  (x/n.cnt  =  yin.  cnt) 

Proof 

invariant,  (x/n.cnt  =  yin.  cnt) 

=  {definition  of  invariant  operator} 

initially,  (x/n.cnt  =  yin. cnt)  a  (x/n.cnt  =  yin. cnt)  next  (x/n.cnt  =  yin. cnt) 

=  {all  inboxes  are  initialized  with  cnt  =  0} 

(x/n.cnt  =  yin. cnt)  next  (x/n.cnt  =  yin. cnt) 

<=  {proof  rule  for  next  operator} 

(Vs  |  5  e  G.T+  (x/n.cnt  =  yin. cnt)  >  {x/n.cnt  =  yin. cnt}  s  {x/n.cnt  =  y/n.cnt}) 

=  {quantification} 

{x/n.cnt  =  yin. cnt}  (1)  {x/n.cnt  =  yin. cnt}  A  {x/n.cnt  =  yin. cnt}  (2)  {x/n.cnt  =  yin. cnt}  A 
{x/n.cnt  =  y/n.cnt}  (3)  {x/n.cnt  =  y/n.cnt}  A  {x/n.cnt  =  y/n.cnt}  (4)  {x/n.cnt  =  y/n.cnt} 


We  prove  each  conjunct  individually: 
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{xln. cnt  =  y/n.cnt}  (1)  {x/n.cnt  =  yin. cnt} 

{definition  of  assertion} 

(x/n.cnt  =  yin. cnt  A  x/n.probe  a  y/n.probe  A  waiting  A  x'  =  x/n.  current  a 
y’  =  y/n.current  a  x/n.advance  a  y/n.advance  a  busy'  =>  xln  . cnt  =  yin  . cnt)  a 
(x/n.cnt  =  yin. cnt  A  -■  (x/n.probe  A  y/n.probe  a  waiting)  =>  xln. cnt  =  yin. cnt) 

{predicate  calculus:  xaj^x} 

x/n.cnt  =  yin. cnt  a  x/n.probe  A  y/n.probe  A  waiting  A  x'  =  xln. current  A 
y'  =  y/n.current  a  x/n.advance  a  y/n.advance  A  busy '  =>  x/n'.cnt  =  yin  . cnt 

{predicate  calculus:  (x^zf^fxAy^  z)} 

x/n.cnt  =  yin. cnt  a  x/n.advance  a  y/n.advance  =>  x/n'.cnt  =  yin  .cnt 
{definition  of  advance  operation} 

x/n.cnt  =  yin. cnt  a  x/n'.cnt  =  x/n.cnt  +  1  a  yin  . cnt  =  yin. cnt  +  1  =>  x/n'.cnt  =  yin  . cnt 
{substitution} 

x/n.cnt  =  yin. cnt  =>  x/n.cnt  +  1  =  yin. cnt  +  1 

{arithmetic} 

true 

- end  of  {xf/i.cnt  =  yin. cnt}  (1)  {x/n.cnt  =  y/n.cnt} 

{x/n.cnt  =  y/n.cnt}  (2)  {x/n.cnt  =  yin. cnt} 

{definition  of  assertion} 

(x/n.cnt  =  y/n.cnt  /\x<y/\y'=y-x^  x/n'.cnt  =  yin  .cnt)  a 
(x/n.cnt  =  y/n.cnt  A  y  <  x  =>  x/n.cnt  =  y/n.cnt) 
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=  {predicate  calculus:  x  a  y  =>  x} 

xln. cnt  =  yin. cnt  a  x  <  y  A  y'  =  y  -  x  =>  x/n'.cnt  =  yin  . cnt 
<=  {predicate  calculus:  (x  =>  z)  =>  (x  A  y  =>  z)} 
x/n.cnt  =  yin. cnt  =>  x/n'.cnt  =  y/n'.cnt 

=  {x/n'.cnt  =  xln. cnt  a  y/n'.cnt  =  yin. cnt,  since  x/n  and  yin  don’t  appear  in  transition  (2)} 
x/n.cnt  =  yin. cnt  =>  x/n.cnt  =  yin. cnt 

=  {predicate  calculus:  x  =>  x} 

true 

- end  of  {x/n.cnt  =  yin. cnt}  (2)  {x/n.cnt  =  y/n.cnt} 

{x/n.cnt  =  y/n.cnt}  (3)  {x/n.cnt  =  y/n.cnt} 

<=  {symmetry  with  transition  (2)} 

true 

- end  of  {x/n.cnt  =  yin. cnt}  (3)  {x/n.cnt  =  y/n.cnt} 

{x/n.cnt  =  y/n.cnt}  (4)  {x/n.cnt  =  y/n.cnt} 

=  {definition  of  assertion} 

(x/n.cnt  =  y/n.cnt  A  x  =  y  a  busy  A  send (targetProcess,  targetlnbox,  x)  A  waiting' a 
x/n'.cnt  =  y/n'.cnt)  a 

(x/n.cnt  =  y/n.cnt  A  ~i(x  =  y  A  busy )  =>  x/n.cnt  =  y/n.cnt) 


{predicate  calculus:  x  a  y  =>  x} 
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xln. cnt  =  y/n.cnt  a  x  =  y  a  busy  A  send(  targetProcess,  targetlnbox,  x)  A  waiting'  A 
xlri .  cnt  =  yin  .  cnt 

<=  {predicate  calculus:  (x  =>  z)  =>  (x  A  y  =>  z)} 
x/n. cnt  =  y/n.cnt  =>  x/n'. cnt  =  y/n'. cnt 

=  {x/n'.cnt  =  xln. cnt  a  y/n'. cnt  =  y/n.cnt,  since  x/n  and  yin  don’t  appear  in  transition  (4)} 
xln. cnt  =  y/n.cnt  =>  xln. cnt  =  y/n.cnt 

=  {predicate  calculus:  x  =>  x} 

true 


- end  of  {xfti.cnt  =  yin. cnt}  (4)  {x/n.cnt  =  yin. cnt} 

Therefore,  the  conjunction  of  all  four  assertions  follows  from  the  predicate  true.  Having 
shown  that  they  are  equal,  we  refer  to  the  values  of  x/n. cnt  and  y/n.cnt  as  cnt  in  the  following 
lemmas.  □ 

Lemma  3.33  (Value  Transience) 

Ifx  and  y  differ  in  a  system  state  S,  then  in  some  system  state  subsequent  to  S  either  the  value 
ofx,  the  value  of  y,  or  both  will  have  changed. 

{MX,  Y  >  transient. (x  y  A  x  =  X  A  y  =  Y)) 


Proof 

{MX,  Y  t>  transient. (x  ^  y  a  x  =  X  a  y  =  Y)) 

4=  {proof  rule  for  transient  operator} 

{MX,  Y  t>  (3x  |  5  e  G.T-{x  J=yAx  =  XAy  =  Y)  > 

{x  *  y  A  x  =  X  a  y  =  Yj  s  {-^{x  *  y  a  x  =  X  a  y  =  Y)})) 


{quantification} 


(VX,  Yt>  {x  =t=  y  A  x  =  X  a  y  =  Y} 
{x±yAX  =  XAy  =  Y} 
{x*yAx  =  XAy  =  Y} 
{x  *  y  A  x  =  X  A  y  =  Y] 

{predicate  calculus:  x=>xvyj 
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(1)  {-<{x  *  y  a  x  =  X  a  y  =  Y)}  v 

(2)  {~>(x  *  y  a  x  =  X  a  y  =  7)}  v 

(3)  {^(x  *  y  a  x  =  X  a  y  =  Y)}  v 

(4)  {-i(x  *  y  a  x  =  X  a  y  =  7)}) 


{ MX,  Y\>{x*yAx  =  XAy 
{x^yAx  =  XAy 


Y}  (2)  {->(x  *  y  a  x 
Y}  (3)  {dxtyAx 


X  a  y 
X  Ay 


l7)}  v 
Y)}) 


We  simplify  each  disjunct  individually: 

{x*yAx  =  XAy  =  Yj  (2)  {-*(x  y  a  x  =  X  a  y  =  Y)} 


{definition  of  assertion} 


{x  ±  y  a  x  =  X  a  y  =  Y  a  x  <  y  A  y'  =  y  -  x  ±  y'  a  x'  =  X  a  y'  =  Y))  a 

{x  *  y  a  x  =  X  a  y  =  Y  A  y  <  x  ^{x  *  y  A  x  =  X  a  y  =  Y)) 

{predicate  calculus:  x  =>  y  =  ->x  v  y} 

(-■(x  y  A  x  =  X  a  y  =  Y  a  x  <  y  a  y'  =  y  -  x)  v  -'(x'  *  y'  ax'  =  X  a  y'  =  Y))  a 
(-i(x  *  y  a  x  =  X  a  y  =  Y  Ay  <  x)  =>  ->(x  =t=  y  a  x  =  X  a  y  =  7)) 

{De  Morgan} 

-i((x  =*=  y  A  x  =  X  a  y  =  Y  a  x  <  y  A  y'  =  y  -  x  A  x'  *  y'  a  x'  =  X  a  y'  =  Y)  v 

(x+3'AX  =  KA3'  =  fAy<XAXtj'AX  =  lAJ  =  f)) 

{Lemma  3.31,  arithmetic:  x>lAy>l^(}'  =  yA/=j-xAy  =  i's  false)} 


^(x  +  yAx  =  LA3'  =  fAy<xAx#yAx  =  lA3'  =  y) 
{predicate  calculus:  x  a  x  =  x} 


(xi=yAx  =  XAy  =  YAy<x) 
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{De  Morgan} 

x=yvxAXvyAYvx<y 


- end  of  {x  *  y  a  x  =  X  a  y  =  Y]  (2)  {-<(x  *  y  a  x  =  X  a  y  =  Y)} 

{x  a  y  A  x  =  X  A  y  =  Y]  (3)  {-i(x  a  y  A  x  =  X  a  y  =  7)} 

<=  {symmetry  with  transition  (2)} 

x  =  yvx=f=Xvy^Yvy<x 


- end  ot{x*yAX  =  XAy=Y]  (3)  {-i(x  *  y  a  x  =  X  a  y  =  7)} 

The  disjunction  of  the  two  assertions  is  as  follows: 

(x  =  3'Vi+Xvy  +  fvx<y)v(x  =  3'Vx+IV)'*yvy<x) 

=  {arithmetic:  x  =  yvx<yvy<x} 

true 

Therefore,  the  disjunction  of  the  two  assertions  follows  from  the  predicate  true.  □ 

Lemma  3.34  (Constraints  on  Value  Changes) 

Ifx  and  y  differ,  then  after  the  next  system  step  either  both  x  and  y  are  unchanged  or  the  sum 
ofx  and  y  is  the  maximum  of  the  previous  values  ofx  and  y. 

(VX,  Y>(x±y/\x  =  X/\y  =  Y)  next  {{x  *  y  A  x  =  X  A  y  =  Y)  v  x  +  y  =  max(V,  Y))) 

Proof 

This  proof  is  similar  in  structure  to  the  proofs  of  Lemmas  3.31  and  3.32  (after  the  decomposi¬ 
tion  into  initially  and  next  properties),  so  we  will  not  present  the  calculations  here.  Note  that 
the  only  two  transitions  that  change  x  and  y  contain  x  a  y  in  their  guard.  If  the  guard  of  one 
of  these  transitions  holds,  the  smaller  of  x  and  y  is  subtracted  from  the  larger,  and  the  sum  of 
x  and  y  in  the  subsequent  state  is  the  maximum  of  the  previous  values  of  x  and  y.  Any  other 
transition  when  x  a  y  preserves  the  values  of  x  and  y .  Therefore,  the  next  property  holds.  □ 
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Lemma  3.35  (Calculation  Progress,  Part  1) 

Ifx  and  y  differ  in  a  system  state  S,  then  in  some  state  subsequent  to  S  the  sum  ofx  and  y  will  be 
the  maximum  of  the  values  ofx  and  y  in  state  S. 

(VX,  Y\>(x*y/\x  =  X/\y  =  Y)~^{x  +  y  =  max(X,  7)) 


Proof 

Let  p  =  x*y/\x  =  X/\y  =  Y,q=x+y  =  max(X,  Y).  Then  we  have: 

(VX,Y>p^>q) 

<=  {basis  rule  for 

( VX,  Y  >  (/?  A  ->q  next  p  v  q)  a  transient.}/?  a  -<q)) 

<=  {next  and  transient  strengthening} 

( MX,  Y  t>  (p  next  p  v  q)  a  transient./?) 

=  {quantihcation} 

( \/X,  Y  t>  p  next  p  v  q)  a  (\/X,  Y  >  transient./?) 

This  predicate  is  exactly  the  conjunction  of  Lemmas  3.33  and  3.34.  Therefore,  the  leads-to 
property  follows  from  those  lemmas.  □ 

Lemma  3.36  (Calculation  Progress,  Part  2) 

Ifx  and  y  differ  in  a  system  state  S,  then  x  and  y  will  be  equal  in  some  state  subsequent  to  S. 

{\/K\x+y  =  K\>x*y^x  =  y) 


Proof 

We  prove  this  lemma  inductively.  For  K  =  2  (the  base  case),  the  only  possible  values  for  x  and 
y  are  x  =  y  =  1,  since  Lemma  3.31  specifies  that  x  and  y  are  positive  integers.  Thus,  we  have 
1  =/=  1  x  =  y,  or  false  ^  x  =  y,  which  holds  by  direct  substitution  into  the  basis  rule  for 
leads-to. 

For  subsequent  values  of  K,  assume  the  leads-to  holds  for  all  2  <  k  <  K .  There  are  two 
cases  to  consider:  either  x  =  y  =  K/2  or  x  y.  If  x  =  y  =  K/2,  the  proof  of  the  leads-to  is 


62 


symmetric  to  that  for  the  base  case  (false  ^  x  =  y).  If  x  =/=  y,  then  Lemma  3.35  says  that  the 
sum  of  x  and  y  will  be  reduced  to  ma  x(x,y)  in  some  later  system  state.  Since  ma  x(x,y)  <  K, 
the  leads-to  holds  for  max(x,  y)  by  induction. 

Therefore,  the  leads-to  holds  for  all  values  of  K  greater  than  1.  □ 

Lemma  3.37  (Calculation  Safety) 

Whenever  at  least  one  pair  of  integers  has  been  read  from  the  inboxes,  the  GCD  ofx  and  y  is 
equal  to  the  GCD  of  the  most  recent  pair  of  integers  read  from  the  inboxes. 

invariant. ( cnt  >  0  =>  GCD(x,3')  =  GCD (?dn[cnt  -  lj.msg,  yln[ cnt  -  lj.msg)) 


Proof 

Observe  that  the  only  transition  that  modifies  cnt  is  transition  (1),  which  (using  the  value  of  cnt 
in  the  post-state)  stores  xbi[  cnt-  lj.msg  and  yln[  cnt- lj.msg  inx  and  y,  respectively.  Observe 
also  that  the  next  property  proven  in  Lemma  3.34  completely  constrains  the  changes  in  x  and 
y  such  that  they  implement  Euclid’s  algorithm  for  GCD  calculation.  One  of  the  characteristics 
of  Euclid’s  algorithm  is  that,  at  every  step,  the  GCD  of  the  two  intermediate  values  is  the  same 
as  the  GCD  of  the  initial  values.  Therefore,  the  invariant  holds.  □ 

Lemma  3.38  (Message  Counts  and  State,  Part  1) 

Assume  that  waiting  holds  and  the  same  number  of  messages  have  been  read  from  each  inbox 
as  have  been  sent  on  the  outbox.  In  the  next  state,  either  waiting  still  holds  and  the  same  number 
of  messages  have  still  been  read  from  each  inbox  as  have  been  sent  on  the  outbox,  or  busy  holds 
and  one  more  message  has  been  read  from  each  inbox  than  has  been  sent  on  the  outbox. 

(VC  |  C  >  0  >  ( waiting  a  cnt  =  CLlen  =  C)  next 

(( waiting  A  cnt  =  CLlen  =  C)  v  ( busy  a  cnt  -  1  =  CLlen  =  C))) 


Proof 

Assume  waiting  A  cnt  =  CLlen  =  C  holds.  The  only  enabled  transition  that  can  change  either 
waiting  or  cnt  is  transition  (1),  and  no  transition  that  can  change  ouf.len  is  enabled.  If  any 
transition  other  than  (1)  is  selected,  waiting  a  cnt  =  CLlen  =  C  is  maintained.  If  transition  (1)  is 
selected,  it  establishes  busy  and  increments  cnt  by  1  as  a  result  of  reading  messages  from  the 
inboxes.  Therefore,  after  execution  of  transition  (1),  busy  a  cnt  -  1  =  CLlen  =  C  holds.  This 
proves  the  next  property.  □ 

Lemma  3.39  (Message  Counts  and  State,  Part  2) 

Assume  that  busy  holds  and  one  more  message  has  been  read  from  each  inbox  than  has  been 
sent  on  the  outbox.  In  the  next  state,  either  busy  still  holds  and  one  more  message  has  still  been 
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read  from  each  inbox  than  has  been  sent  on  the  outbox,  or  waiting  holds  and  the  same  number 
of  messages  have  been  read  from  each  inbox  as  have  been  sent  on  the  outbox. 

(VC  |  C  >  0  t>  (busy  A  cnt  -  1  =  O.len  =  C)  next 

((busy  a  cnt  -  1  =  O.len  =  C)  v  (waiting  A  cnt  =  O.len  =  C  +  1))) 


Proof 

Assume  busy  A  cnt  -  1  =  O.len  =  C  holds.  The  only  enabled  transition  that  can  change 
either  busy  or  ouf.len  is  transition  (4),  and  no  transition  that  can  change  cnt  is  enabled.  If  any 
transition  other  than  (4)  is  selected,  busy  A  cnt  -  1  =  O.len  =  C  is  maintained.  If  transition  (4) 
is  selected,  it  establishes  waiting  and  increments  out.len  by  1  as  a  result  of  sending  a  message 
on  the  outbox.  Therefore,  after  execution  of  transition  (4),  waiting  a  cnt  =  O.len  =  C  +  1  holds. 
This  proves  the  next  property.  □ 

Lemma  3.40  (Calculation  Termination) 

If  busy  holds  in  a  system  state  S  and  x  and  y  differ  in  state  S,  then  x  and  y  will  be  equal  to  each 
other  and  to  the  GCD  of  the  most  recent  pair  of  integers  read  from  the  inboxes  in  some  state 
subsequent  to  S. 

(VC  |  C  >  0  >  (busy  A  cnt  -  l  =  CAx#y)^ 

(busy  a  cnt  -  \  =  C  ax  =  y  =  GCD(xbi[C].msg,y/n[C].msg))) 


Proof 

This  property  follows  from  an  application  of  the  basis  rule  for  leads-to  with  Lemmas  3.36  and 
3.39.  The  invariant  proven  in  Lemma  3.37  shows  that  x  and  y  always  have  the  same  GCD  as 
x/n[C].msg  and  y/n[C].msg,  so  when  x  =  y,  their  value  must  by  definition  be  that  GCD.  □ 

Lemma  3.41  (Communication  Safety,  Part  1) 

If  waiting  holds  in  a  system  state  where  there  are  messages  waiting  on  both  xln  and  yin,  then 
in  the  next  system  state  either  this  remains  the  case  or  busy  holds  and  a  message  has  been  read 
from  each  inbox. 

(VC  |  C  >  0  >  (waiting  a  cnt  =  C  a  a/o. probe  a  y//i. probe)  next 

((waiting  A  cnt  =  C  a  a/o. probe  a  y/n.probe)  v 

(busy  a  cnt  -  l  =  C  a  x  =  x/n[C].msg  a  y  =  y/n[C].msg))) 
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Proof 

Assume  waiting  holds  and  there  are  messages  waiting  on  both  xln  and  yin.  The  only  enabled 
transition  is  transition  (1),  and  its  effect  is  to  establish  busy  and  (by  means  of  the  current  and 
advance  operations)  set  x  and  y  to  x/n[C].msg  and  y/n[C].msg,  respectively,  and  increment 
cnt.  This  proves  the  next  property.  □ 

Lemma  3.42  (Waiting  Transience) 

If  waiting  holds  in  a  system  state  S  where  there  are  messages  waiting  on  both  xln  and  yin,  then 
waiting  will  be  falsified  in  some  system  state  subsequent  to  S. 

transient. (waiting  a  xln. probe  a  y/n.  probe) 


Proof 

Assume  waiting  holds  and  messages  are  waiting  on  x/n  and  yin.  The  only  enabled  transition 
is  transition  (1),  which  falsifies  waiting.  It  must  eventually  be  selected  because  of  the  weak 
fairness  requirement  on  program  execution.  Therefore,  the  transient  property  holds.  □ 

Lemma  3.43  (Communication  Progress,  Part  1) 

If  waiting  holds  in  a  system  state  S  where  there  are  messages  waiting  on  xln  and  yin,  then  in 
some  system  state  subsequent  to  S  the  next  messages  on  xln  and  yin  will  have  been  read. 

(VC  |  C  >  0  >  ( waiting  a  cnt  -  1  =  C  A  x/n.probe  a  y/n.probe)  ^ 

( busy  a  cnt  -  1  =  C  a  GCD (x,y)  =  GCD(x/n[C].msg,y/n[C].msg))) 


Proof 

This  property  follows  from  an  application  of  the  basis  rule  for  leadsto  with  Lemmas  3.41  and 

3.42.  □ 

Lemma  3.44  (Communication  Safety,  Part  2) 

If  busy  holds  in  a  system  state  where  x  and  y  are  equal  to  each  other  and  to  the  GCD  of  the  most 
recent  pair  of  integers  read  from  the  inboxes,  then  in  the  next  state  either  this  remains  the  case 
or  waiting  holds  and  the  GCD  has  been  sent  on  the  outbox. 

(VC  |  C  >  0  t>  ( busy  A  x  =  y  =  GCD(x/n[C].msg,  y/n[C].msg))  next 

((busy  a  x  =  y  =  GCD(x/n[C].msg, y/n[C].msg))  v 

(waiting  ax  =  y  =  0[C].msg  =  GCD(x/n[C].msg,y/n[C].msg))) 
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Proof 

Assume  busy  holds  and  x  =  y.  The  only  enabled  transition  is  transition  (4),  and  its  effect  is 
to  establish  waiting  and  (by  means  of  the  send  operation)  set  (9[C].msg  to  x.  This  proves  the 
next  property.  □ 

Lemma  3.45  (Busy  Transience) 

If  busy  holds  in  a  system  state  S  where  x  and  y  are  equal  to  each  other,  then  busy  will  be  falsified 
in  some  system  state  subsequent  to  S. 

transient.  ( busy  a  x  =  y ) 


Proof 

Assume  busy  holds  and  x  =  y.  The  only  enabled  transition  is  transition  (4),  which  falsifies 
busy.  It  must  eventually  be  selected  because  of  the  weak  fairness  requirement  on  program 
execution.  Therefore,  the  transient  property  holds.  □ 

Lemma  3.46  (Communication  Progress,  Part  2) 

If  busy  holds  in  a  system  state  S  where  x  and  y  are  equal  to  each  other  and  to  the  GCD  of  the 
most  recent  pair  of  integers  read  from  the  inboxes,  then  in  some  system  state  subsequent  to  S 
the  GCD  will  have  been  sent  on  the  outbox. 

(VC  |  C  >  0  >  ( busy  ax  =  y  =  GCD(x/n[C].msg, yJn[C].msg)) 

(waiting  ax  =  y  =  (9[C].msg  =  GCD(x/n[C].msg,y/n[C].msg))) 


Proof 

This  property  follows  from  an  application  of  the  basis  rule  for  leads-to  with  Lemmas  3.44  and 

3.45.  □ 

Lemma  3.47  (Initial  Conditions) 

In  the  initial  state,  waiting  holds  and  the  same  number  of  messages  have  been  read  from  each 
inbox  as  have  been  sent  on  the  outbox. 

initially. (waiting  A  cnt  =  O.len  =  0) 


Proof 

The  initially  property  follows  immediately  from  the  initially-section  of  GCDCalculator  and  the 
fact  that  all  mailboxes  are  empty  at  initialization.  □ 
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Theorem  3.48  (GCD  Calculation  and  Communication) 

The  sequence  of  integers  on  the  outbox  follows  the  sequence  containing  the  GCDs  of  pairs  of 
messages  on  the  inboxes. 


(9. msg  follows  GCDSeq(x/n.msg,  y/n.msg) 


Proof 

In  order  to  prove  this  follows  relation,  we  must  prove  the  five  components  of  the  follows 
definition.  For  this  follows  property,  they  are: 


(Vs  >  stable.) (9 .msg  >  s))  (1) 

(Vs  >  stable.  (GCDSeq(x/n.msg,  y/n.msg)  >5))  (2) 

invariant. ( (9 .msg  <  GCDSeq(x/n.msg,  y/n.msg))  (3) 

(Vs  >  GCDSeq(x/n.msg,  yin. msg)  >  s  (9  .msg  >  s)  (4) 

(Vs  o  GCDSeq(x/n.msg, y/n.msg)  =  s  a  (9. msg  <  s  next  (9 .msg  <  s)  (5) 


Since  xln  and  yin  are  inboxes,  xln.msg  and  yin. msg  are  monotonic  by  definition.  The  appli¬ 
cation  of  GCDSeq  to  them  is  therefore  monotonic.  This  proves  component  (1)  of  the  definition. 

Since  O  is  an  outbox,  O .msg  is  monotonic  by  definition.  This  proves  component  (2)  of  the 
definition. 

Initially,  both  the  outbox  and  the  inboxes  are  empty,  so  (9  .msg  is  initially  a  subsequence 
of  GCDSeq(x/n.msg,  y/n.msg).  By  Lemmas  3.38-3.39,  3.43,  and  3.46,  the  GCD  of  every  pair 
of  messages  read  from  the  inboxes  will  eventually  be  written  to  the  outbox  in  the  order  the 
messages  are  read,  and  the  number  of  messages  written  to  the  outbox  is  never  more  than  one 
fewer  than  the  number  of  messages  read  from  each  inbox.  Therefore,  every  write  to  the  outbox 
preserves  the  invariant  in  component  (3)  of  the  definition,  as  O.msg  remains  a  subsequence  of 
GCDSeq(x/n.msg,  y/n.msg).  The  fact  that  every  pair  of  messages  will  eventually  be  processed 
proves  component  (4)  of  the  definition,  and  the  fact  that  the  number  of  messages  written  to 
the  outbox  never  exceeds  the  number  of  messages  read  from  each  inbox  proves  component  (5) 
of  the  definition. 

Therefore,  the  follows  property  holds,  and  we  have  proven  our  desired  property.  □ 

In  the  following  three  chapters,  we  will  present  systems  composed  of  multiple  Dynamic 
UNITY  programs.  We  will  omit  most  of  the  calculations  in  our  proofs  of  these  systems,  as 
those  proofs  are  similar  in  structure  to  the  ones  we  have  presented  here. 
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Chapter  4 

Deterministic  Example:  The  Prime 
Number  Sieve 


We  now  present  the  first  of  our  example  Dynamic  UNITY  systems,  Eratosthenes’  prime  number 
sieve.  This  example  is  chosen  for  its  determinism;  we  know  the  computations  that  must  be 
done  to  generate  the  set  of  prime  numbers,  so  we  can  easily  check  that  our  system  implements 
the  algorithm  correctly.  Our  particular  system  illustrates  one  of  Dynamic  UNITY’S  strengths, 
by  generating  an  unbounded  number  of  running,  communicating  processes  while  still  ensuring 
progress. 

4.1  Problem  Statement 

The  problem  statement  for  this  example  is  straightforward:  “Generate  an  infinite  sequence 
of  integers  such  that  the  ith  element  of  the  sequence  is  the  ith  prime  number.”  We  know  of 
an  algorithm  to  generate  arbitrarily  large  prime  numbers:  Eratosthenes’  prime  number  sieve. 
We  can  use  Dynamic  UNITY’S  communication  and  process  creation  capabilities  to  create  an 
infinitely  large  prime  number  sieve,  and  thereby  generate  our  infinite  sequence  (provided  that 
we  allow  our  system  to  run  for  infinite  time). 

We  choose  to  implement  each  sieve  element  as  its  own  Dynamic  UNITY  process,  with  knowl¬ 
edge  only  about  the  previous  and  next  elements  in  the  sieve.  We  wish  to  implement  a  Dynamic 
UNITY  system  that  actually  generates  the  infinite  sequence  of  prime  numbers,  so  we  also  need 
a  process  that  feeds  integers  into  the  sieve.  We  choose  to  have  a  central  “collection  point”  for 
the  prime  numbers,  so  that  we  can  keep  our  generated  sequence  in  one  place.  This  allows  us 
to  reason  about  the  sequence  and  its  changes,  rather  than  reasoning  simultaneously  about  the 
states  of  an  infinite  number  of  processes.  For  simplicity,  and  to  preserve  the  ordering  of  the 
sequence,  the  process  that  acts  as  the  collection  point  and  the  process  that  feeds  integers  into 
the  sieve  are  the  same  process. 
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For  the  purposes  of  this  discussion,  we  assume  that  the  only  messages  being  sent  in  our 
system  are  integer  messages.  This  minimizes  our  proof  obligations  and  makes  the  programs 
less  complicated,  because  we  don’t  need  to  worry  about  filtering  out  non-integer  messages  that 
may  arrive  on  the  inboxes. 

We  specify  the  sieve  element  program  first,  describing  and  proving  properties  of  its  behavior 
in  isolation,  and  then  do  the  same  for  the  sequence  generator  and  collector  program.  Finally, 
we  compose  the  two  programs  to  create  a  prime  number  sieve. 


4.2  The  Sieve  Program 


program  Sieve(previous:  process,  sieveValue:  integer,  sequenceNumber:  integer) 
declare 

numberln,  primeln:  inbox 
next:  process 

always 

remainder  =  numberln.current.msg  mod  sieveValue 

initially 

send(previous,  “primeln”,  sieveValue)  A  next  =  _L 

fair-transition 

(1)  primeln.probe  — * 

send(previous,  “primeln”,  primeln.current.msg)  A  primeln.advance 

(2)  0  number In.probe  A  remainder  =  0  — *  numberln.advance 

(3)  0  numberln.probe  A  remainder  ^  0  A  next  =  _L  — * 

next'  =  new  Sieve(this,  numberln.current.msg,  sequenceNumber  +  1) 

(4)  0  numberln.probe  A  remainder  ^  0  A  next  =f=  ±  — > 

send(next,  “numberln”,  numberln.current.msg)  A  numberln.advance 

end 


Specification  4.1:  The  Sieve  program,  part  of  the  infinite  prime  number  sieve  system 


The  Sieve  program  acts  as  a  biter,  taking  two  integer  sequences  as  inputs  (from  the  numberln 
and  primeln  inboxes)  and  generating  outputs  based  on  these  sequences  and  its  instantiation 
parameters.  Additionally,  each  Sieve  program  is  responsible  for  creating  the  next  Sieve  program 
in  the  system.  In  order  to  show  that  the  Sieve  program  biters  these  sequences  correctly,  we 
must  establish  certain  properties;  we  brst  prove  that  the  Sieve  program  is  well-formed: 

Theorem  4.1  (Sieve  Well-Formedness) 

The  Sieve  program  is  well-formed. 
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Proof 

We  prove  that  the  Sieve  program  is  well-formed  by  showing  that  its  always-section,  initially- 
section,  and  transition-sections  are  well-formed: 

always-section  The  always-section  of  the  Sieve  program  contains  a  single  definition,  which  is 
a  simple  function  of  2  integers.  There  are  no  circular  definitions,  and  no  undefined  variables 
are  referenced.  Therefore,  the  always-section  is  well-formed. 

initially-section  The  initially-section  of  the  Sieve  program  sends  a  message  and  initializes 
next  to  the  empty  process.  Neither  of  these  actions  is  capable  of  causing  an  infinite  recursion, 
and  both  of  them  are  satishable.  Therefore,  the  initially-section  is  well-formed. 

transition-sections  For  each  transition,  we  must  demonstrate  that  its  postcondition  is  always 
satishable  if  its  precondition  holds.  We  do  this  individually  for  the  four  transitions: 

•  The  postcondition  of  transition  (1)  is  the  conjunction  of  a  message  send  (which  is  always 
satishable)  and  an  inbox  advance  (which  is  always  satishable).  Therefore,  transition  (l)’s 
postcondition  is  always  satishable. 

•  The  postcondition  of  transition  (2)  is  an  inbox  advance,  which  is  always  satishable. 

•  The  postcondition  of  transition  (3)  is  a  process  instantiation,  which  is  always  satishable. 

•  The  postcondition  of  transition  (4)  is  the  conjunction  of  a  message  send  (which  is  always 
satishable)  and  an  inbox  advance  (which  is  always  satishable).  Therefore,  transition  (4)’s 
postcondition  is  always  satishable. 

Since  all  sections  of  the  Sieve  program  are  well-formed,  the  entire  program  is  well-formed. 

□ 

We  now  prove  safety  and  progress  properties  that  show  that  the  Sieve  process  hlters  the  in¬ 
teger  sequences  as  necessary  to  implement  Eratosthenes’  algorithm.  We  introduce  the  function 
SIEVE  for  use  in  the  following  proofs.  This  function  takes  as  parameters  a  sequence  of  integers 
and  a  single  integer,  and  generates  as  a  result  the  sequence  of  integers  that  was  passed  to  it 
with  all  elements  divisible  by  the  single  integer  parameter  removed.  We  also  use  the  notation 
“box.msg”  to  refer  to  the  sequence  of  messages  contained  in  inbox  or  outbox  box  (that  is,  the 
sequence  “box[0].msg,  box[  \  ].msg,  ...,  hox[hox.len  -  Fj.msg”). 
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Theorem  4.2  (Sieve  Number  Output  Sequence) 

The  sequence  of  messages  sent  to  inboxes  named  “numberin’’  follows  the  sequence  of  messages 
received  on  numberln,  with  integers  divisible  by  sieveValue  removed  from  the  sequence. 


(O  lm  Mi- m box  =  “numberln” ).msg  follows  S 1 EV E  ( mr m be rln . m sg ,  sieve Va lue) 


Proof 

To  prove  this  follows  relation,  we  must  prove  the  five  components  of  the  follows  definition. 
In  the  following  equations  and  their  proofs,  we  denote  SIEVH(numberIn.msg,  sieveValue)  by 
numberlnSieved  and  (O  \m  m.mbox  =  “numberln”)  by  numberOut: 


(Vs  >  stable. ( numberOut. msg  >  s ))  (1) 

(Vs  >  stable. (numberlnSieved  >  s))  (2) 

invariant. (numberOut. msg  <  numberlnSieved)  (3) 

(Vs  t>  ( numberlnSieved  >  s)  (numberOut. msg  >  s))  (4) 

(Vs  t>  ( numberlnSieved  =  s  A  numberOut. msg  <  s)  next  (numberOut. msg  <  s))  (5) 


We  address  these  individually: 

1.  Since  numberOut  is  a  filtered  outbox,  numberOut. msg  is  monotonic  by  definition. 

2.  Since  numberln  is  an  inbox,  numberln. msg  is  monotonic  by  definition.  Additionally,  sieve¬ 
Value  does  not  change  during  execution  because  it  is  a  parameter  to  the  Sieve  program. 
This  implies  that  numberlnSieved  is  monotonic,  because  SIEVE  always  removes  the  same 
elements  of  a  monotonic  sequence. 

3.  Two  transitions,  (2)  and  (4),  perform  advance  operations  on  numberin',  the  other  transi¬ 
tions  do  not  modify  the  state  of  either  numberln  or  O,  and  can  therefore  not  affect  this 
invariant).  Transition  (2)  advances  numberln  to  the  next  message  and  does  nothing  with 
the  current  message;  it  executes  only  when  remainder  is  0,  which  occurs  when  the  current 
message  is  evenly  divisible  by  sieveValue.  Transition  (4)  advances  numberln  to  the  next 
message  and  appends  the  current  message  to  numberOut  (by  sending  a  message  to  an  in¬ 
box  named  “numberin’’);  it  executes  only  when  remainder  is  not  0,  which  occurs  when  the 
current  message  is  not  evenly  divisible  by  sieveValue.  Since  both  of  these  commands  are 
guarded  by  numberln. probe,  and  both  contain  advance  operations,  exactly  one  of  them 
executes  for  each  message  in  inbox  numberln.  The  SIEVE  function  removes  exactly  those 
elements  of  the  sequence  that  are  evenly  divisible  by  its  parameter,  in  this  case  sieve- 
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Value,  which  is  exactly  what  transition  (2)  does.  Therefore,  numberOut.msg  is  always  a 
subsequence  of  numberlnSieved. 

4.  From  the  previous  equation,  we  know  that  numberOut.msg  is  always  a  subsequence  of 
numberlnSieved.  Weak  fairness  ensures  that  all  4  transitions  of  the  Sieve  program— and 
in  particular,  transition  (4)— will  be  selected  infinitely  often.  As  long  as  numberOut.msg  T 
numberlnSieved,  transition  (4)  will  at  some  point  execute  when  selected  (transition  (2)  may 
execute  a  finite  number  of  times  first),  extending  numberOut.msg.  Therefore,  if  at  some 
point  numberlnSieved  is  a  supersequence  of  a  sequence  s,  numberOut.msg  will  become  a 
supersequence  of  s  after  some  finite  number  of  executions  of  (4). 

5.  The  only  way  for  the  sequence  numberOut.msg  to  increase  is  by  means  of  transition 
(4),  which  reads  a  message  from  numberln  and  sends  it  to  an  inbox  named  “numberln.” 
Therefore,  numberOut.msg  can  never  exceed  the  previous  state  of  numberlnSieved. 

All  five  components  of  the  original  follows  relation  hold.  Therefore,  the  follows  relation 
holds.  □ 

Theorem  4.3  (Sieve  Prime  Output  Sequence) 

The  sequence  of  messages  sent  to  inboxes  named  “primeln”  follows  the  sequence  of  messages 
received  on  primeln,  with  sieveValue  prepended  to  the  sequence. 

( O  \m  m.mbox  =  “primeln” ).msg  follows  (sieveValue  M  primeln. msg) 


Proof 

To  prove  this  follows  relation,  we  must  prove  the  following  5  components  of  the  follows  def¬ 
inition.  In  the  following  equations  and  their  proofs,  we  denote  (sieveValue  M  primeln.msg)  by 
extendedPrimeln  and  (O  lm  m.mbox  =  “primeln”)  by  primeOut,  for  brevity: 


<  V5  >  stable. (primeOut. msg  >  5))  (1) 

( \/s  >  stable. (extendedPrimeln  >  s))  (2) 

invariant. (primeOut. msg  <  extendedPrimeln)  (3) 

(Vto  ( extendedPrimeln  >  s)  ^  (primeOut. msg  >  s))  (4) 

(\/s  o  (extendedPrimeln  =  5  A  primeOut.msg  <  s)  next  (primeOut. msg  <  s))  (5) 


We  address  these  individually: 


1.  Since  primeOut  is  a  filtered  outbox,  primeOut. msg  is  monotonic  by  definition. 
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2.  Since  primeln  is  an  inbox,  primeln. msg  is  monotonic  by  definition.  Additionally,  sieve- 
Value  does  not  change  during  execution,  because  it  is  a  parameter  to  the  Sieve  program. 
Therefore,  extendedPrimeln  is  monotonic. 

3.  Only  transition  (1)  and  the  initialization  of  the  Sieve  program  change  primeOut. msg.  At  ini¬ 
tialization,  sieveValue  is  sent  to  an  inbox  named  “primeln”  (and  thus  added  to  primeOut). 
Since  primeOut.msg  is  monotonic,  this  means  that  the  first  element  of  primeOut.msg  is 
always  sieveValue.  Transition  (1)  takes  the  next  message  from  primeln  and  appends  it  to 
primeOut  (by  sending  it  to  an  inbox  named  “primeln”),  and  advances  primeln ;  it  executes 
exactly  once  for  each  message  in  primeln,  and  appends  each  message  from  primeln  to 
primeOut  in  the  order  it  was  received.  Therefore,  primeOut. msg  is  always  a  subsequence 
of  extendedPrimeln. 

4.  From  the  previous  equation,  we  know  that  primeOut. msg  is  always  a  subsequence  of  ex¬ 
tendedPrimeln.  Weak  fairness  ensures  that  all  4  transitions  of  the  Sieve  program— and 
in  particular,  transition  (1)— will  be  selected  infinitely  often.  As  long  as  primeOut. msg 
f  extendedPrimeln,  transition  (1)  will  execute  when  selected,  extending  primeOut. msg. 
Therefore,  if  at  some  point  extendedPrimeln  is  a  supersequence  of  a  sequence  s,  prime¬ 
Out.msg  will  become  a  supersequence  of  s  after  some  finite  number  of  executions  of  (1). 

5.  The  only  way  for  the  sequence  primeOut. msg  to  increase  is  by  means  of  transition  (1), 
which  reads  a  message  from  primeln  and  sends  it  to  an  inbox  named  “primeln.”  Therefore, 
primeOut. msg  can  never  exceed  the  previous  state  of  extendedPrimeln. 

All  five  components  of  the  follows  definition  hold.  Therefore,  the  follows  relation  holds.  □ 

Finally,  we  prove  properties  that  show  that  the  Sieve  program  creates  the  next  Sieve  process, 
with  appropriate  parameters,  when  necessary. 

Theorem  4.4  (Next  Sieve  Process  Stability) 

Once  next  refers  to  a  process,  it  refers  to  the  same  process  forever. 

(Vp  |  p  _L  t>  stable. (next  =  p)) 


Proof 

Initially,  next  =  _L.  There  is  only  one  transition,  (3),  which  assigns  a  value  to  next  by  creating  a 
new  process.  Transition  (3)  is  guarded  by  next  =  _l;  it  can  therefore  only  execute  once  during 
the  process’  entire  execution,  because  thereafter  next  will  have  a  non-_L  value.  Since  there  are 
no  other  transitions  that  change  the  value  of  next,  the  stable  properties  hold.  □ 
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Theorem  4.5  (Next  Sieve  Process  Existence) 

If  one  or  more  messages  have  been  sent  to  an  inbox  called  “numberln,  ”  there  exists  a  next  sieve 
process. 

invariant. ( 1 0  lm  m.mbox  =  “numberin’’!  >  0  =>  next  f  _l) 


Proof 

There  is  only  one  transition,  (4),  which  sends  a  message  to  an  inbox  called  “numberln.”  This 
transition  is  guarded  by  next  f  1,  so  no  message  is  sent  to  an  inbox  called  “numberln”  unless 
this  guard  holds. 

From  Theorem  4.4,  we  know  that  next  ±  is  stable.  Therefore,  if  any  message  has  been 
sent  to  an  inbox  called  “numberln,”  the  condition  next  f  ±  holds.  This  proves  our  implication. 

□ 

Theorem  4.6  (Next  Sieve  Process  Creation  Safety) 

At  all  times  during  the  execution  of  the  Sieve  program,  exactly  one  of  the  following  three  condi¬ 
tions  holds:  (a)  No  next  process  has  been  created,  and  no  number  that  is  not  evenly  divisible  by 
sieveValue  has  been  received  on  numberln;  (b)  No  next  process  has  been  created,  and  at  least 
one  number  that  is  not  evenly  divisible  by  sieveValue  has  been  received  on  numberln;  or  (c)  A 
next  process  has  been  created  with  its  sieveValue  parameter  set  to  the  first  number  received  on 
numberln  that  is  not  evenly  divisible  by  sieveValue. 


invariant. 

( ( next  =  _L  a 

(a) 

(Vn  |  0  <  n  <  numberln. lent>  numberln[n]. msg  mod  sieveValue  =  0))  v 
( next  =  _L  a 

(3 n  |  0  <  n  <  numberln. lem>  numberln[n], msg  mod  sieveValue  0)  A  (b) 
numberln. cnt  <  (min  n  \  numberln[n\. msg  mod  sieveValue  =  0  >  n))  v 
( next  = 

Sieve  (primeln, 

numberln[ (min  n  \  number In[n], msg  mod  sieveValue  =  0  >  n)],  (c) 

sequenceNumber  +  1)  A 

numberln. cnt  >  (min  n  \  numberln[n\. msg  mod  sieveValue  =  0  >  n))) 

Proof 

The  three  disjuncts  of  the  invariant  are  mutually  exclusive,  by  inspection.  Initially,  disjunct  (a) 
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holds,  because  the  numberln  inbox  is  empty  and  the  variable  next  is  initialized  to  _L. 

We  now  show  that  each  of  the  possible  transitions  maintains  the  invariant.  Since  the  invari¬ 
ant  contains  no  reference  to  primeln ,  transition  (1)  always  maintains  the  invariant,  because  it 
only  modifies  primeln.  We  therefore  ignore  transition  (1)  for  the  remainder  of  this  proof. 

When  disjunct  (a)  holds,  the  only  transition  that  can  be  executed  is  (2),  since  there  is  no 
message  in  numberln  that  yields  a  remainder  when  divided  by  sieveValue.  This  transition 
maintains  disjunct  (a),  because  it  does  not  change  the  contents  of  numberln  (it  merely  changes 
numberln. cnt).  Additionally,  when  disjunct  (a)  holds,  a  message  can  be  received  on  numberln. 
If  this  message  is  evenly  divisible  by  sieveValue,  disjunct  (a)  is  maintained;  otherwise,  disjunct 
(b)  is  established  because  there  now  exists  a  message  in  numberln  that  is  not  evenly  divisible 
by  sieveValue. 

When  disjunct  (b)  holds,  the  only  transitions  that  can  be  executed  are  (2)  and  (3),  which  are 
mutually  exclusive.  If  (2)  is  executed,  disjunct  (b)  is  maintained,  because  next  is  unchanged. 
If  (3)  is  executed,  disjunct  (c)  is  established  because  execution  of  (3)  reads  the  first  value  in 
numberln  that  is  not  evenly  divisible  by  sieveValue  and  assigns  to  next  a  new  Sieve  process 
whose  parameters  are  exactly  those  specified  in  disjunct  (c). 

When  disjunct  (c)  holds,  the  only  transitions  that  can  be  executed  are  (2)  and  (4).  Both  of 
these  maintain  (c),  because  neither  changes  next  and  because  of  the  monotonicity  of  inbox  and 
outbox  message  sequences. 

We  have  now  shown  that  the  invariant  holds,  because  it  holds  initially  and  every  transition 
takes  the  system  from  a  state  where  one  of  the  disjuncts  holds  to  another  state  where  one  of 
the  disjuncts  holds.  □ 

Theorem  4.7  (Next  Sieve  Process  Creation  Progress) 

If  a  number  that  is  not  evenly  divisible  by  sieveValue  is  received  on  numberln,  the  next  Sieve 
process  will  be  created  in  finite  time. 

transient. ( next  =  1  A  (3n  |  0  <  n  <  numberln. len>  number Jji[n].msg  mod  sieveValue  f  0)) 
Proof 

The  state  we  wish  to  show  transience  of  corresponds  to  disjunct  (b)  of  Theorem  4.6.  Recall 
that  the  only  transitions  that  can  be  executed  in  this  state  are  (2)  and  (3),  which  are  mutually 
exclusive.  Since  some  element  of  numberln  exists  that  is  not  divisible  by  sieveValue,  let  N 
be  the  index  of  that  element,  and  let  numberln. cnt  =  n  <  N.  If  transition  (2)  is  executed, 
numberln.cnt  is  incremented  from  its  pre-execution  value,  which  must  be  strictly  less  than  N. 
N  remains  unchanged,  because  of  the  monotonicity  of  inbox  message  sequences.  Therefore, 
weak  fairness  ensures  that  numberln. cnt  will,  after  a  finite  number  of  executions  of  transition 
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(2),  be  incremented  to  N.  When  numberln. cnt  =  N,  the  precondition  of  transition  (3)  holds, 
and  it  must  therefore  be  executed  in  accordance  with  weak  fairness.  Execution  of  transition  (3) 
invalidates  disjunct  (b)  of  Theorem  4.6,  which  proves  the  transient  property.  □ 

We  have  now  shown  all  the  behavior  of  the  Sieve  in  isolation  that  we  need  to  prove  the 
correctness  of  the  composed  system. 


4.3  The  Generator  Program 


program  Generator 
declare 

primeln:  inbox 
sequenceNumber:  integer 
next:  process 
num:  integer 

primes:  sequence  {integer} 

initially 

primes  =  A  A  num  =  2  a  next  =  new  Sieve(this,  2,  1)  A  sequenceNumber  =  0 

fair-transition 

(1)  send(next,  “numberln”,  num)  A  num'  =  num  +  1 

(2)  Q  primeln.probe  — *  primes'  =  primes  M  primeln.current.msg  a  primeln.advance 


end 


Specification  4.2:  The  Generator  program,  part  of  the  infinite  prime  number  sieve  system 


The  functions  of  the  Generator  program  are  to  feed  the  sequence  of  positive  integers  start¬ 
ing  from  2  into  the  prime  number  sieve,  and  to  accept  the  sequence  of  prime  numbers  from 
the  sieve.  Additionally,  the  Generator  program  is  responsible  for  creating  the  first  Sieve  pro¬ 
cess  (corresponding  to  2,  the  first  prime  number).  For  the  purpose  of  proving  properties  of 
the  Generator  in  isolation,  we  assume  that  a  well-formed  program  named  Sieve  which  takes 
3  initialization  parameters  (a  process  and  two  integers)  and  which  creates  no  processes  dur¬ 
ing  its  initialization  exists  in  the  same  system  as  the  Generator,  without  making  any  other 
assumptions  about  that  program’s  specification.  We  first  prove  that  the  Generator  program  is 
well-formed. 

Theorem  4.8  (Generator  Well-Formedness) 

The  Generator  program  is  well-formed. 
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Proof 

We  prove  that  the  Generator  program  is  well-formed  by  showing  that  its  always-section,  initially- 
section,  and  transition-sections  are  well-formed: 

always-section  The  Generator  program  has  no  always-section. 

initially-section  The  initially-section  of  the  Generator  program  instantiates  a  Sieve  process. 
To  show  that  the  Generator  program’s  initially-section  is  well-formed,  we  must  show  that  this 
instantiation  is  not  infinitely  recursive  and  that  the  initially-section  as  a  whole  is  satishable.  The 
Sieve  program’s  initially-section  does  not  instantiate  any  processes,  so  there  is  no  recursion. 
Moreover,  all  conjuncts  of  the  Generator  program’s  initially-section  are  satishable.  Therefore, 
the  Generator  program’s  initially-section  is  well-formed. 

transition-sections  For  each  transition,  we  must  demonstrate  that  its  postcondition  is  always 
satishable  if  its  precondition  holds.  We  do  this  individually  for  the  two  transitions: 

•  The  postcondition  of  transition  (1)  is  the  conjunction  of  a  variable  increment  and  a  mes¬ 
sage  send,  both  of  which  are  always  satishable.  Therefore,  transition  (l)’s  postcondition 
is  always  satishable. 

•  The  postcondition  of  transition  (2)  is  the  conjunction  of  an  append  of  a  received  mes¬ 
sage  to  a  sequence  and  an  inbox  advance  operation,  both  of  which  are  always  satishable. 
Therefore,  transition  (2)’s  postcondition  is  always  satishable. 

Since  all  sections  of  the  Generator  program  are  well-formed,  the  entire  program  is  well- 
formed.  □ 

We  now  prove  safety  and  progress  properties  that  show  that  the  sequence  sent  by  the  Gen¬ 
erator  program  on  its  outbox  is  exactly  the  sequence  of  positive  integers  starting  from  2,  and 
that  the  number  of  integers  sent  always  increases. 

Theorem  4.9  (Generator  Output  Sequence  Safety) 

The  outbox  of  a  Generator  process  contains  a  sequence  of  integer  messages  beginning  with  the 
number  2: 

invariant. (( V i  |  0  <  i  <  (9.1en[>  (9[i].msg  =  2  +  i)) 

In  order  to  prove  this  theorem,  we  need  to  establish  a  relation  between  O.len  and  num.  We 
do  so  with  the  following  lemma: 
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Lemma  4.10  (Relation  between  (9. len  and  num) 

For  all  Generator  processes,  the  difference  between  the  value  of  integer  variable  num  and  the 
number  of  messages  in  the  process’s  outbox  is  always  2: 

invariant.  ( num  -  (9.1en  =  2) 


Proof 

Initially,  num  =  2  and  (9  .len  =  0  (because  an  outbox  contains  no  messages  at  initialization,  and 
there  are  no  message  sends  in  the  initially-section  of  program  Generator).  Therefore,  num  - 
(9  .len  =  2  holds  immediately  after  process  initialization. 

Transition  (1)  contains  a  send  operation  that  sends  a  single  message,  incrementing  (9.1en 
by  1  due  to  the  semantics  of  the  message  passing  system,  and  explicitly  increments  num  by 
i.  Since  incrementing  two  integers  by  the  same  value  doesn’t  change  their  difference,  num  - 
(9  .len  =  2  holds  immediately  after  an  execution  of  transition  (1)  if  it  held  before  the  execution. 

Transition  (2)  contains  no  message  sends  and  no  references  to  num,  and  therefore  does  not 
affect  the  invariant.  □ 

Proof  of  Theorem  4.10  (Generator  Output  Sequence  Safety) 

Initially,  (9  .len  =  0,  so  the  quantification  is  over  an  empty  range  (0  <  i  <  0)  and  holds  vacu¬ 
ously.  The  only  transition  that  changes  (9  .len  is  transition  (1),  which  (owing  to  the  semantics 
of  send)  assigns  to  numberOut[numberOut.len].msg  the  value  of  the  integer  variable  num,  and 
increments  both  (9  .len  and  num.  From  Lemma  4.10,  we  know  that  num  -  (9  .len  =  2  before 
every  execution  of  transition  (1).  We  can  therefore  conclude  that  the  value  of  each  message  in 
numberOut  is  its  index  in  numberOut  plus  2.  □ 

Theorem  4.11  (Generator  Output  Sequence  Progress) 

The  outbox  of  a  Generator  process  always  has  a  new  message  added  to  it  in  finite  time: 

{ Vi  |  i  >  0  >  transient. ( 6 .len  =  i )) 


Proof 

The  Generator  program  only  has  two  transitions.  The  weak  fairness  property  ensures  that 
transition  (1)  will  always  be  executed  after  transition  (2)  has  been  executed  a  finite  number  of 
times  and,  as  we  established  in  the  proof  of  Lemma  4.10,  transition  (1)  increments  the  value 
of  O  .len  by  1.  Since  the  Generator  program  does  not  contain  a  stop  statement,  it  runs  forever. 
This  means  that  no  matter  what  the  value  of  O  .len  is  at  a  given  point  in  the  program’s  execution, 
it  will  always  be  incremented  at  some  point  later  in  the  execution.  □ 
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Next,  we  show  that  the  sequence  primes  follows  the  sequence  of  messages  received  on 
channel  primeln. 

Theorem  4.12  (Generator  Input  Sequence) 

The  sequence  primes  follows  the  message  history  of  primeln. 

primes  follows  primeln. msg 


Proof 

To  prove  this  follows  relation,  we  must  prove  the  following  5  components  of  the  follows  defi¬ 
nition: 


(Vs  [>  stable. (primes  >  s))  (1) 

( Vs  >  stable. (primeln.msg  >  s))  (2) 

invariant.  ( primes  <  primeln. msg)  (3) 

(Vs  >  (primeln. msg  >  s)  ( primes  >  s))  (4) 

( Vs  >  (primeln. msg  =  s  a  primes  <  s)  next  (primes  <  s))  (5) 


We  address  these  individually: 

1.  There  is  one  transition  which  appends  elements  to  primes,  and  there  are  no  transitions 
that  remove  elements  from  primes.  Therefore,  primes  is  monotonic. 

2.  Since  primeln  is  an  inbox,  primeln. msg  is  monotonic  by  definition. 

3.  One  transition,  (2),  performs  an  advance  operation  on  primeln.  When  it  does  this,  it  also 
appends  the  current  message  to  primes.  Since  this  transition  is  guarded  by  primeln. probe, 
it  executes  exactly  once  for  each  message  on  primeln.  Both  primeln. msg  and  primes  are 
initially  empty  sequences  (and  therefore  subsequences  of  each  other),  and  this  transition 
always  maintains  that  subsequence  relationship. 

4.  From  the  previous  equation,  we  know  that  primes  is  always  a  subsequence  of  primeln. msg. 
Weak  fairness  ensures  that  both  transitions  of  the  Sieve  program— and  in  particular,  tran¬ 
sition  (2)— will  be  selected  infinitely  often.  As  long  as  primes  f  primeln. msg,  transition  (2) 
will  at  some  point  execute  when  selected,  extending  primes.  Therefore,  if  at  some  point 
primeln. msg  is  a  supersequence  of  a  sequence  s,  primes  will  become  a  supersequence  of 
s  after  some  finite  number  of  executions  of  (2). 
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5.  The  only  way  for  the  sequence  primes  to  increase  is  by  means  of  transition  (2),  which 
reads  a  message  from  primeln  and  appends  it  to  primes.  Therefore,  primes  can  never 
exceed  the  previous  state  of  primeln. msg. 

All  five  components  of  the  follows  definition  hold.  Therefore,  the  follows  relation  holds.  □ 
Finally,  we  prove  that  the  process  referred  to  by  next  remains  the  same  throughout  the 
execution  of  the  Generator  program. 

Theorem  4.13  (Generator  Next  Reference  Stability) 

Once  a  process  is  instantiated  and  a  reference  to  that  process  is  assigned  to  next  in  the  Generator 
program,  next  refers  to  that  process  forever: 

{ V  p  t>  stable.  ( next  =  p ) ) 


Proof 

Initially,  next  is  assigned  to  be  a  reference  to  a  new  instance  of  the  Sieve  program  with  a 
specific  set  of  parameters.  No  transition  in  the  Generator  program  modifies  the  next  reference. 
Therefore,  next  refers  to  the  same  instance  of  the  Sieve  program  forever.  □ 

Finally,  we  show  that  the  Generator’s  sequenceNumber  variable  is  always  set  to  0.  Though 
this  does  not  seem  like  an  interesting  property  in  isolation,  it  will  prove  useful  when  we  con¬ 
struct  the  proof  of  the  composed  system. 

Theorem  4.14  (Generator  Sequence  Number) 

The  sequenceNumber  variable  of  a  Generator  process  is  always  set  to  0. 

invariant.  (sequenceAiumber  =  0) 


Proof 

At  initialization,  sequenceNumber  is  set  to  0.  No  transition  of  the  Generator  program  changes 
sequenceNumber.  Therefore,  sequenceNumber  is  always  set  to  0. 

We  have  now  shown  all  the  behavior  of  the  Generator  in  isolation  that  we  will  need  to  use 
in  our  proof  of  correctness  for  the  composed  system. 

4.4  The  Composed  System 

The  composed  system  contains  the  Generator  program  (Specification  4.2)  as  an  initial  program, 
as  well  as  the  Sieve  program  (Specification  4.1).  We  now  prove  that  the  entire  system  actually 
implements  a  prime  number  sieve,  by  proving  three  theorems  about  the  system  using  the 
properties  we  have  already  proven  about  the  Generator  and  Sieve  programs  in  isolation. 
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system  InfinitePrimeNumberSieve 

initial-program  Generator 

program  Sieve(previous:  process,  sieveValue:  integer,  sequenceNumber:  integer) 
end 


Specification  4.3:  The  InfinitePrimeNumberSieve  system 


Theorem  4.15  (Generator  Process  Uniqueness/Stability) 

There  is  always  exactly  one  Generator  process  in  the  InfinitePrimeNumberSieve  system,  and  this 
process  never  stops. 

Proof 

We  need  to  prove  that  a  single  Generator  process  is  created  in  every  possible  execution  of 
the  system,  that  it  never  stops,  and  that  it  is  impossible  for  any  more  to  be  created  after  it. 
Generator  is  the  initial  program  of  the  system,  so  a  single  instance  of  Generator  is  created  at 
system  initialization  time.  Theorem  4.8  shows  that  the  Generator  program  is  well-formed,  and 
by  inspection  it  does  not  contain  a  stop  statement.  Therefore,  in  accordance  with  Dynamic 
UNITY  execution  semantics,  it  runs  forever.  Also  by  inspection,  neither  the  Generator  program 
nor  the  Sieve  program  contains  a  statement  that  instantiates  a  Generator  process.  This  means 
that  no  other  Generator  process  is  ever  instantiated  during  the  execution  of  the  system.  □ 

Theorem  4.16  (Global  Safety) 

At  all  times,  the  primes  sequence  contained  in  the  Generator  process  is  comprised  of  the  first 
primes. length  prime  numbers  in  increasing  order. 

In  order  to  prove  this  theorem,  we  must  show  first  that  the  sieveValue  parameters  of  the 
Sieve  processes  in  the  system  are  prime  numbers,  and  then  that  the  primes  sequence  consists  of 
these  sieveValue  parameters,  in  order.  We  first  prove  several  lemmas  that  allow  us  to  construct 
a  proof  of  global  safety. 

Lemma  4.17  (Sieve  Uniqueness) 

For  any  sequence  number  n,  there  is  at  most  one  Sieve  process  in  the  system  with  that  sequence 
number. 

invariant.((  Vp,  q,  u,  v,  w,  x,  y,  z  \ 

p,qeT  A  p  =  Sieve(u,  v,  w)  a  q  =  Sieve(x,  y,  z)  >  (tu  =  z)  =>  (p  =  q))) 
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Proof 

Sieve  processes  are  created  in  one  of  two  ways:  by  the  Generator  at  initialization  time,  or  by  a 
Sieve  process  after  initialization  time.  Theorem  4.4  tells  us  that  when  a  Sieve  process  creates 
another  Sieve  process,  that  process  is  stable  (that  is,  no  other  Sieve  process  is  ever  created  by 
the  creating  Sieve  process),  while  Theorem  4.13  tells  us  the  same  for  the  Generator  process. 
Therefore,  all  we  need  to  show  is  that  every  time  a  Sieve  process  is  created,  it  is  created  using  a 
sequence  number  that  has  not  been  used  before.  This  follows  directly  from  the  program  text  of 
the  Sieve  program,  since  transition  (3)  of  Sieve  increments  the  sequence  number  when  creating 
a  new  Sieve  process.  □ 

Lemma  4.18  (Sieve  Sequence) 

The  sequence  numbers  of  the  Sieve  processes  in  the  system  accurately  reflect  their  position  in  the 
chain  of  Sieve  processes. 

invariant.((  \/s,  p,v,n  \  s  G  T  a  s  =  Sieve(p,  v,  n)  > 

p.sequenceNumber  =  n  -  1  A 

( s.next  =  _L  v  ( s.next  ±  a  s.next.sequenceNumber  =  n  +  1)))) 


Proof 

The  Generator,  which  is  the  first  process  to  be  created  in  the  system,  always  has  sequenceNum- 
ber  =  0,  by  Theorem  4. 14.  As  part  of  the  Generator’s  initialization,  it  creates  a  Sieve  process  with 
sequenceNumber  =  1,  with  itself  as  the  Sieve’s  previous  process.  Therefore,  after  creation  of  the 
first  Sieve  process  s,  the  invariant  holds:  s .sequenceNumber  =  1,  s .previous.sequenceNumber 
=  0,  and  s.next  =  _L. 

We  now  show,  by  induction,  that  all  subsequent  Sieve  process  creations  maintain  the  in¬ 
variant.  Assume  we  have  n  Sieve  processes  numbered  k,  k  +  1,  ...,  k  +  n  -  1  in  the  system, 
and  denote  the  nth  Sieve  process  by  S(n)  (so  we  have  the  relation  S  (n)  .sequenceNumber  = 
k  +  n  -  1).  The  invariant,  if  it  holds,  must  hold  with  5  (n).  next  =  ±  (if  it  doesn’t,  there  is 
an  (n  +  1 ) st  Sieve  process  we  are  not  accounting  for).  If  transition  (3)  of  S{n)  is  not  exe¬ 
cuted,  the  invariant  is  maintained  because  no  new  Sieve  process  is  created  and  S(n).next  is 
not  changed.  If  transition  (3)  is  executed,  a  new  Sieve  process  S(n  +  1)  is  created  such  that 
5 (n  +  1) .sequenceNumber  =  S (n) .sequenceNumber  +  1  and  S(n+  l).next=  _L.  This  preserves 
the  invariant,  since  S(n). next  =  S (n  + 1 )  and  S(n  +  1 ) . previous  =  S(n),  and  we  have  now  proven 
the  invariant  for  n  +  1  Sieve  processes.  As  the  validity  of  our  base  case,  w  =  1,  has  been  shown 
above,  this  completes  the  induction.  □ 
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Corollary  4.19  (Sieve  Connections) 

Every  Sieve  process's  previous  process  has  that  Sieve  as  a  next  process. 

invariant.  ((Vs,  p,v,n  \  s  £  T  A  s  =  Sieve(p,  v,  n)  t>  p.next  =  s)) 


Proof 

Combining  Lemmas  4.17  and  4.18  immediately  gives  us  this  corollary  -  together,  they  show 
that  there  is  a  single  chain  of  Sieve  processes  in  the  system,  in  which  each  Sieve  is  connected 
exactly  to  its  predecessor  and,  if  one  exists,  its  successor.  □ 

Lemma  4.20  (Messaging  Connections) 

For  every  Sieve  process  S,  the  message  sequence  of  inbox  S.numberln  follows  the  sequence  of 
messages  sent  on  0S.previous  f0  jn  boxes  named  “numberln,”  and  the  message  sequence  of  inbox 
S.previous.primeln  follows  the  sequence  of  messages  sent  on  (9s  to  inboxes  named  “primeln." 

{Ms,p,v,n  \  s  &  T  a  s  =  Sieve(p,  v,  n)  \> 

s.numberln. msg  follows  (Op  lm  m.mbox  =  “numberln”). msg  a 

p. primeln. msg  follows  (0s  1  m  m.mbox  =  “primeln”). msg) 


Proof 

By  inspection,  all  messages  sent  by  any  process,  Generator  or  Sieve,  to  an  inbox  named  “num¬ 
berin’’  are  sent  to  the  inbox  with  that  name  belonging  to  the  next  process.  Because  of  Lemmas 
4.17  and  4.18,  we  can  also  tell  by  inspection  that  no  messages  are  sent  to  that  inbox  from  any 
other  outbox  belonging  to  any  process  in  the  system,  and  that  the  “numberln”  inbox  of  a  Sieve 
process  is  always  the  variable  numberln.  Therefore,  by  the  channel  theorem  (Theorem  3.11), 
the  sequence  of  messages  in  the  numberln  inbox  of  a  Sieve  process  follows  the  sequence  of 
messages  in  the  outbox  of  its  predecessor  which  are  addressed  to  inboxes  named  “numberln.” 
An  analogous  proof  applies  to  the  sequence  of  messages  in  the  outbox  of  a  Sieve  process  which 
are  addressed  to  inboxes  named  “primeln”  and  its  predecessor’s  primeln  inbox.  □ 

Corollary  4.21  (Sieve  Process  Outgoing  Number  Sequences) 

For  every  Sieve  process  S,  the  sequence  of  messages  sent  on  0s  to  inboxes  named  “numberln” 
follows  the  sequence  of  messages  sent  on  (ps  previous^  a//  integers  divisible  by  S.sieveValue 
removed. 
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(Vs,  p,v ,n  \  s  G  T  a  s  =  Si eve(p,  u,  n)  t> 

(0s  im  m.mbox  =  “numberin’’) .msg  follows 

SIEVE((Op  lm  m.mbox  =  “numberin’’). msg,  v)) 


Proof 

This  corollary  follows  immediately  from  Lemma  4.20  and  Theorem  4.2.  □ 

Elereafter,  we  will  denote  ( Ok  lm  m.mbox  =  “numberin’’)  by  k.numberOut,  and  ( Ok  lm 
m.mbox  =  “primeln”)  by  k.primeOut,  for  brevity. 

Lemma  4.22  (Prime  Sieve  Values) 

The  sieveValue  of  the  Sieve  process  with  sequence  number  n  is  the  nth  prime  number. 

Proof 

We  prove  this  by  induction  on  the  sequence  numbers  of  the  Sieve  processes,  using  our  knowl¬ 
edge  of  the  initial  Sieve’s  parameters,  the  output  sequence  of  the  Generator,  and  the  rules 
governing  prime  numbers.  For  sequence  number  1,  the  lemma  holds  because  the  Sieve  initial¬ 
ized  with  sequence  number  1  is  initialized  with  sieve  value  2,  and  2  is  the  first  prime  number. 
This  is  our  base  case. 

Now,  assume  we  have  n  Sieve  processes  Si,  S2,  ■  ■  ■  ,Sn,  with  sequence  numbers  1,  2,  ...,  n 
and  sieve  values  p\,  p>,  . ..,  pn,  such  that  for  all  i,  p,  is  the  ith  prime  number.  We  need  to 
show  that  when  Sieve  process  S^+i  is  created  (with  sequence  number  n  +  1),  its  sieve  value 
Pn+\  is  the  ( n  +  1 ) st  prime  number.  From  Corollary  4.21,  we  know  that  Sn-numberOut.msg 
follows  SIEVE(Sn  \.numberOut.msg,  pn).  This  relation  also  applies  to  the  numberOut.msg  se¬ 
quence  of  every  other  Sieve  process.  Therefore,  all  elements  of  S n-i- numberOut. msg  are  not 
divisible  by  any  of  pi,  p2, . . . ,  Pn- 1  ■  Additionally,  we  know  from  Theorem  4.9  that  the  number- 
Ouf.msg  sequence  of  the  Generator,  which  is  the  previous  process  to  Si,  is  exactly  the  sequence 
2,  3,  ....  Therefore,  the  numberOut.msg  sequence  of  Sn  is  exactly  the  sequence  which  results 
when  all  elements  divisible  by  pi  are  removed  from  the  initial  sequence,  then  all  elements  di¬ 
visible  by  p 2  are  removed  from  the  resulting  sequence,  etcetera,  all  the  way  up  to  all  elements 
divisible  by  pn  being  removed  from  Sn-numberln. msg.  This  is  exactly  the  Eratosthenes’  prime 
number  sieve  algorithm. 

Since  pn  is  prime,  the  first  element  of  Sn-numberOut. msg— that  is,  the  first  element  of 
Sn-i-numberOut.msg  not  divisible  by  pn — must  be  prime  as  well,  because  a  number  that  is  not 
divisible  by  any  prime  number  less  than  itself  is  prime.  Moreover,  it  is  the  first  prime  number 
greater  than  pn,  because  of  the  particular  integer  sequence  being  fed  into  the  system  by  the 
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Generator.  This  element  becomes  pn+ 1,  the  sieveValue  for  process  Sn+\,  as  shown  in  Theorem 
4.6.  Since  pi,  p 2,  ■  ■  ■  ,Pn  are  the  1st,  2nd,  ...,  nth  prime  numbers,  pn+ 1  is  the  (n  +  1 ) st  prime 
number.  □ 

Corollary  4.23  (Sieve  Process  Prime  Sequences) 

For  every  Sieve  process  S,  the  message  sequence  of  S.primeOut  follows  the  message  sequence  of 
S.next.primeOut  with  S. sieveValue  prepended. 

(Vs,  p,v,n  \  s  s  T  a  s  =  Si eve(p,  v,  n)  \> 

s. primeOut.msg  follows  ( v  X  s.next.primeOut.msg)) 


Proof 

This  corollary  follows  immediately  from  Lemma  4.20  and  Theorem  4.3. 

Proof  of  Theorem  4.16  (Global  Safety) 

The  primes  sequence  in  the  Generator  process  follows  primeOut  of  the  Sieve  process  with 
sequenceNumber  1,  by  Lemma  4.20  and  Theorems  4.12  and  4.14.  This  sequence,  by  Lemma 
4.22  and  repeated  application  of  Corollary  4.23,  is  exactly  the  sequence  of  prime  numbers 
starting  from  2.  □ 

Theorem  4.24  (Global  Progress) 

The  primes  sequence  never  remains  the  same  length  forever. 

(Vn  |  n  >  0  >  (primes.length  =  n)  (primes.length  >  n)) 


Proof 

Global  progress  follows  immediately  from  Theorems  4.11,  4.12  and  4.3  and  Corollaries  4.21 
and  4.23.  □ 
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Chapter  5 

Nondeterministic  Example:  Single 
Resource  Mutual  Exclusion 


Our  second  example  Dynamic  UNITY  system  is  a  simple  mutual  exclusion  algorithm,  where 
clients  request  a  single  resource  from  a  central  server  and  are  served  in  the  order  of  their 
requests.  We  demonstrate  the  ability  of  Dynamic  UNITY  processes  to  leave  the  system,  by 
allowing  clients  to  leave  the  system  at  any  time  during  their  execution.  We  also  make  use  of 
unfair  transitions,  another  feature  of  Dynamic  UNITY,  in  this  example. 

5.1  Problem  Statement 

The  problem  statement  for  this  example  is  as  follows:  “Given  a  shared  resource  and  a  changing 
set  of  clients  that  require  access  to  the  resource,  ensure  that  only  one  client  at  a  time  has  access 
to  the  resource  and  that  no  client  that  requests  access  to  the  resource  is  forced  to  wait  forever 
for  that  access.”  The  most  straightforward  way  of  accomplishing  this  is  to  have  a  request  queue, 
so  that  requests  for  the  resource  are  processed  in  the  order  in  which  they  are  received.  Dynamic 
UNITY  gives  us  such  a  queuing  mechanism,  the  inbox,  as  part  of  its  messaging  framework. 

We  implement  the  resource  (more  accurately,  the  process  that  manages  access  to  the  re¬ 
source)  as  a  single  Dynamic  UNITY  process,  and  each  client  as  a  Dynamic  UNITY  process.  Ac¬ 
cess  to  the  resource  is  controlled  by  a  token,  which  is  reflected  in  the  states  of  the  resource 
and  the  clients:  the  resource  is  holding  a  token  when  its  idle  definition  holds,  and  the  client  is 
holding  a  token  when  its  busy  definition  holds.  Every  message  passed  in  the  system  contains 
either  one  token  or  no  tokens;  there  are  no  multiple-token  messages. 

In  addition  to  the  basic  mutual  exclusion  algorithm,  we  give  the  clients  the  ability  to  leave 
the  system  at  any  time  during  their  execution  to  better  simulate  a  real  resource  allocation 
system  (in  which  a  consumer  may  decide  to  abandon  a  request  for  a  resource  if  that  request  is 
not  serviced  within  a  reasonable  time). 
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We  specify  the  components  of  our  system  individually,  describe  and  prove  properties  of 
their  behavior  in  isolation,  and  then  compose  them  to  solve  the  problem. 


5.2  The  Resource  Program 


program  Resource 
declare 

requestln,  releaseln:  inbox 
releases:  multiset  {process} 
current:  process 

always 

idle  =  current  =  _l; 
busy  =  -udle 

initially 

current  =  _L  a  releases  =  0 

fair-transition 

(1)  idle  A  requestln.probe  — * 

requestln.advance  A  current'  =  requestln.current.proc  A 
send(requestIn.current.proc,  “tokenin’’,  0) 

(2)  0  busy  A  current  G  releases  — *  current'  =  _L  a  releases'  =  releases  \  {current} 

(3)  0  releaseln.probe  — * 

releaseln.advance  A  releases'  =  releases  u  {releaseln.current.proc} 

end 


Specification  5.1:  The  Resource  program,  part  of  the  single  resource  mutual  exclusion  system 


The  Resource  program  is  responsible  for  ensuring  mutually  exclusive  access  to  a  resource, 
by  handling  requests  and  releases  sent  to  appropriately-named  inboxes  and  sending  tokens  to 
appropriate  destinations.  In  isolation,  we  can  prove  that  the  Resource  program  is  well-formed, 
that  it  always  gets  a  token  back  before  sending  another  token,  and  that  its  message  histories 
and  other  state  variables  fulfill  certain  other  restrictions  that  will  be  important  to  the  proof  of 
the  composed  system. 

Theorem  5.1  (Resource  Well-Formedness) 

The  Resource  program  is  well-formed. 

Proof 

We  prove  that  the  Resource  program  is  well-formed  by  showing  that  its  always-section,  initially- 
section,  and  transition-sections  are  well-formed: 
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always-section  The  always-section  of  the  Resource  program  contains  two  definitions.  The 
first  is  a  simple  Boolean  function  of  a  variable  and  a  constant,  and  the  second  is  the  negation 
of  the  first.  These  definitions  are  not  circular,  and  no  undefined  variables  are  referenced. 
Therefore,  the  always-section  is  well-formed. 

initially-section  The  initially-section  of  the  Resource  program  initializes  a  set  to  the  empty 
set,  and  a  process  to  _L.  There  is  no  recursion,  and  both  conjuncts  of  the  initially  predicate  are 
satishable.  Therefore,  the  initially-section  is  well  formed. 

transition-sections  For  each  transition,  we  must  demonstrate  that  its  postcondition  is  always 
satishable  if  its  precondition  holds.  We  do  this  individually  for  the  three  transitions: 

•  The  postcondition  of  transition  (1)  is  the  conjunction  of  an  inbox  advance,  an  assignment 
to  a  variable  and  a  message  send.  All  of  these  are  always  satishable.  Therefore,  transition 
(l)’s  postcondition  as  a  whole  is  always  satishable. 

•  The  postcondition  of  transition  (2)  is  the  conjunction  of  an  assignment  to  a  variable  and 
a  set  difference  operation,  both  of  which  are  always  satishable.  Therefore,  transition  (2)’s 
postcondition  is  always  satishable. 

•  The  postcondition  of  transition  (3)  is  the  conjunction  of  an  inbox  advance  and  a  set  union 
operation,  both  of  which  are  always  satishable.  Therefore,  transition  (3)’s  postcondition 
is  always  satishable. 

Since  all  sections  of  the  Resource  program  are  well-formed,  the  entire  program  is  well- 
formed.  □ 

Theorem  5.2  (Resource  Process  Serving  Safety) 

A  Resource  only  senses  one  process  at  a  time.  That  is,  if  current  refers  to  a  process,  then  current 
always  changes  to  ±  before  changing  to  refer  to  a  different  process. 

(Vc  |  c  ±  -L  >  current  =  c  next  ( current  =  c  v  current  =  _l)) 


Proof 

When  current  =  c  ^  _L,  the  only  enabled  transitions  are  (2)  and  (3).  Transition  (2)  changes 
current  to  _L,  so  it  satishes  the  next  properties.  Transition  (3)  does  not  change  current,  so  it 
also  satishes  the  next  properties.  Additionally,  changes  in  inbox  states  due  to  arriving  messages 
do  not  change  current.  Therefore,  the  next  properties  hold.  □ 
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Theorem  5.3  (Resource  Per-process  Message  Histories) 

For  every  process  in  the  system  that  is  not  the  process  referred  to  by  current,  the  difference 
between  the  number  of  releases  a  Resource  has  received  from  that  process  and  the  number  of 
tokens  it  has  sent  to  that  process  is  exactly  the  number  of  times  that  process  appears  in  the 
releases  multiset.  For  the  process  referred  to  by  current  when  a  Resource  is  busy,  the  difference 
between  the  number  of  releases  the  Resource  has  received  from  that  process  and  the  number 
of  tokens  it  has  sent  to  that  process  is  exactly  the  number  of  times  that  process  appears  in  the 
releases  multiset  minus  1. 

invariant.  (( V  p  \  p  G  P  a  p  =f=  current  > 

( releaseln  \m  m.proc  =  p).cnt  -  (O  \m  m.proc  =  p).len  = 

(#q  |  q  G  releases  l >  q  =  p)))  (a) 


invariant.  ( busy  => 

( releaseln  lm  m.proc  =  current) .cnt  -  (O  im  m.proc  =  current) .len  = 

{#p  |  p  G  releases  t>  p  =  current)  -  1))  (b) 


Proof 

Initially,  both  invariants  hold  because  current  is  initialized  to  _L  and  all  mailbox  histories  are 
empty,  giving  0  -  0  =  0,  a  tautology,  for  all  instances  of  (a)  and  false  =>  0-0  =  -1,  which 
simplifies  to  true,  for  (b).  We  now  show  that  each  transition  maintains  both  invariants. 

Transition  (1)  is  enabled  only  when  current  =  _L,  so  for  all  processes  p  in  the  system  (_L 
can  never  be  an  actual  process),  an  instance  of  invariant  (a)  holds  as  a  precondition.  Transition 
(1)  sends  a  single  message  to  a  particular  process  and  sets  current  to  refer  to  that  process 
(falsifying  idle  and  establishing  busy)-,  it  does  not  change  the  releases  multiset  or  the  releaseln 
mailbox  state.  By  inspection,  it  maintains  (b)  by  establishing  both  its  left  and  right  sides  while 
maintaining  (a)  for  all  processes  other  than  the  new  current. 

Transition  (2)  is  enabled  only  when  busy  holds,  so  it  executes  with  the  right  side  of  invariant 
(b)  as  a  precondition.  It  decreases  the  number  of  instances  of  current  in  the  releases  multiset  by 
1,  and  establishes  idle  (falsifying  busy).  Invariant  (a)  is  maintained,  because  the  former  current 
now  satisfies  (a)  (by  substitution),  and  invariant  (b)  is  maintained  because  busy  is  falsified. 

Transition  (3)  advances  releaseln,  receiving  a  message  from  a  process  p,  and  also  increases 
the  number  of  instances  of  p  in  the  releases  multiset  by  1 .  It  therefore  maintains  both  invari¬ 
ants,  by  simple  arithmetic.  □ 
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Theorem  5.4  (Resource  Per-process  Request/Token  Safety) 

For  every  process  in  the  system,  the  number  of  token  messages  sent  by  a  Resource  to  that  process 
is  exactly  the  number  of  requests  the  Resource  has  read  from  that  process. 

invariant. (( V p  \  p  e  T  >  (O  lm  m. proc  =  p).len  =  ( requestln  lm  m. proc  =  p).cnt)) 

Proof 

Initially,  the  invariant  holds  because  the  Resource’s  mailboxes  are  all  empty.  There  is  only  one 
transition,  (1),  which  sends  messages,  and  it  also  is  the  only  transition  that  receives  messages 
on  requestln.  Every  time  it  executes,  it  receives  a  single  message  on  requestln  and  sends  a  single 
message  to  the  process  that  sent  the  message  it  received  on  requestln.  Therefore,  both  sides  of 
the  invariant’s  equality  are  incremented  by  1  every  time  transition  (1)  executes.  Since  no  other 
transition  changes  either  side  of  the  equality,  the  invariant  is  maintained.  □ 

Theorem  5.5  (Resource  Request  Handling  Progress) 

If  a  Resource  is  idle  and  there  is  a  request  waiting  in  its  requestln  inbox,  the  process  that  sent 
the  request  will  be  served. 

(\/p  |  p  e?  >  idle  a  requestln.  probe  a  reguesf/n.  current,  proc  =  p  current  =  p) 

Proof 

Transition  (1)  is  the  only  transition  that  reads  from  requestln,  and  it  is  guarded  by  idle  and 
requestln. probe.  It  is  a  fair  transition,  so  it  must  execute  at  some  point  if  its  precondition  is 
stable.  By  inspection,  we  can  see  that  no  other  transition  falsifies  idle,  so  the  precondition 
must  be  stable.  Therefore,  transition  (1)  executes  at  some  point  after  the  left  side  of  any  one  of 
our  set  of  leads-to  conditions  holds.  The  postcondition  of  transition  (1)  for  any  given  message 
source  is  exactly  the  right  side  of  our  leads-to  condition  for  that  message  source.  Therefore, 
the  entire  set  of  leads-to  conditions  holds.  □ 

Theorem  5.6  (Resource  Release  Handling  Progress) 

If  a  Resource  has  received  more  releases  from  its  current  client  than  it  has  sent  tokens  to  that 
client,  the  Resource  will  eventually  become  idle. 

busy  A  (releaseln  \m  m.proc  =  current). cnt  >  (O  im  m. proc  =  current)  .len  ^  idle 

Proof 

From  Theorem  5.3,  we  know  that  if  the  left  side  of  our  leads-to  holds,  there  is  at  least  one 
instance  of  current  in  the  releases  multiset.  This  means  that  the  precondition  for  transition  (2) 
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holds,  and  continues  to  hold  until  transition  (2)  is  executed  (because  transition  (2)  is  the  only 
transition  that  removes  an  element  from  the  multiset  or  negates  busy).  Transition  (2)  is  a  fair 
transition,  and  weak  fairness  tells  us  that  it  will  execute  eventually  if  its  precondition  holds 
and  is  stable.  Its  postcondition  includes  idle,  which  proves  our  leads-to.  □ 

We  have  now  shown  all  the  behavior  of  the  Resource  in  isolation  that  we  will  need  to  use  in 
our  proof  of  correctness  for  the  composed  system. 


5.3  The  Client  Program 


program  Client(resource:  process) 
declare 

idle,  waiting,  busy:  boolean 
tokenln:  inbox 

always 

gone  =  -■idle  A  -■waiting  A  -■busy 


initially 

idle  =  true  a  waiting  =  false  A  busy  =  false 
fair-transition 

(1)  waiting  A  tokenln.probe  — *  waiting'  =  false  a  busy'  =  true  A  tokenln.advance 

(2)  0  busy  — *  busy'  =  false  a  idle'  =  true  a  send(resource,  “releaseln”,  0) 

unfair-transition 

(3)  D  idle  — ►  idle'  =  false  a  waiting'  =  true  a  send(resource,  “requestin’’,  0) 

(4)  0  idle  — ►  idle'  =  false  a  stop 

(5)  0  waiting  — *  waiting'  =  false  A  send(resource,  “releaseln”,  0)  A  stop 

(6)  0  busy  — ►  busy'  =  false  a  send(resource,  “releaseln”,  0)  A  stop 

end 


Specification  5.2:  The  Client  program,  part  of  the  single  resource  mutual  exclusion  system 


The  Client  program  sends  requests  and  releases,  and  receives  tokens;  it  is  considered  to 
have  access  to  whatever  resource  it  needs  when  it  holds  a  token.  We  can  prove  in  isolation  that 
the  Client  program  is  well-formed,  that  it  never  sends  two  requests  without  receiving  a  token 
in  between,  and  that  its  message  histories  and  other  state  variables  fulfill  certain  restrictions 
that  will  be  useful  later  in  proving  the  correctness  of  the  composed  system. 

Theorem  5.7  (Client  Well-Formedness) 

The  Client  program  is  well-formed. 
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Proof 

We  prove  that  the  Client  program  is  well-formed  by  showing  that  its  always-section,  initially- 
section,  and  transition-sections  are  well-formed: 

always-section  The  always-section  of  the  Client  program  contains  one  definition,  which  is  a 
simple  Boolean  function  of  three  variables.  There  are  no  circular  definitions,  and  no  undefined 
variables  are  referenced.  Therefore,  the  always-section  is  well-formed. 

initially-section  The  initially-section  of  the  Client  program  initializes  three  Boolean  variables. 
There  is  no  recursion,  and  all  three  conjuncts  of  the  initially  predicate  are  satishable.  Therefore, 
the  initially-section  is  well  formed. 

transition-sections  For  each  transition,  we  must  demonstrate  that  its  postcondition  is  always 
satishable  if  its  precondition  holds.  We  do  this  individually  for  the  six  transitions: 

•  The  postcondition  of  transition  (1)  is  the  conjunction  of  an  inbox  advance  and  two  assign¬ 
ments  to  variables,  all  of  which  are  always  satishable.  Therefore,  transition  (l)’s  postcon¬ 
dition  is  always  satishable. 

•  The  postcondition  of  transition  (2)  is  the  conjunction  of  two  assignments  to  variables  and 
a  message  send,  all  of  which  are  always  satishable.  Therefore,  transition  (2)’s  postcondi¬ 
tion  is  always  satishable. 

•  The  postcondition  of  transition  (3)  is  the  conjunction  of  two  assignments  to  variables  and 
a  message  send,  all  of  which  are  always  satishable.  Therefore,  transition  (3)’s  postcondi¬ 
tion  is  always  satishable. 

•  The  postcondition  of  transition  (4)  is  the  conjunction  of  an  assignment  to  a  variable  and 
stop,  both  of  which  are  always  satishable.  Therefore,  transition  (4)’s  postcondition  is 
always  satishable. 

•  The  postcondition  of  transition  (5)  is  the  conjunction  of  an  assignment  to  a  variable,  a 
message  send  and  stop,  all  of  which  are  always  satishable.  Therefore,  transition  (5)’s 
postcondition  is  always  satishable. 

•  The  postcondition  of  transition  (6)  is  the  conjunction  of  an  assignment  to  a  variable,  a 
message  send,  and  stop,  all  of  which  are  always  satishable.  Therefore,  transition  (6)’s 
postcondition  is  always  satishable. 

Since  all  sections  of  the  Client  program  are  well-formed,  the  entire  program  is  well-formed. 

□ 
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Theorem  5.8  (Client  State  Transitions  Safety) 

Only  one  of  idle,  waiting,  busy  and  gone  holds  for  a  Client  at  any  given  point  during  its  execution. 
All  Client  transitions  are  either  from  idle  to  waiting,  from  waiting  to  busy,  from  busy  to  idle,  or 
from  any  of  these  to  gone.  The  gone  state  is  stable. 

invariant.  ( ( idle  =>  ->  waiting  A  ->  busy  A  -1  gone)  A  ( waiting  =>  -1  busy  a  -1  gone  A  -1  idle) 

(1) 

A  ( busy  =>  -■ gone  A  -1 idle  a  -1 waiting )  A  ( gone  =>  -'idle  A  -1 waiting  A  ~^busy)) 


idle  next  ( idle  v  waiting  v  gone)  (2) 

waiting  next  ( waiting  v  busy  v  gone)  (3) 

busy  next  ( busy  v  idle  v  gone)  (4) 

stable,  gone  (5) 


Proof 

We  prove  each  of  the  5  equations  individually: 

1.  We  can  eliminate  the  ( gone  =>  -1  idle  A  -■ waiting  A  ~^busy)  conjunct  immediately;  gone 
is  defined  as  ->  idle  A  waiting  A  -1  busy,  so  the  implication  is  a  tautology.  For  the  same 
reason,  we  can  replace  ~^gone  with  true  in  the  antecedents  of  the  other  three  conjuncts. 
What  we  have  left  to  prove  is  that  only  one  of  idle,  waiting  and  busy  ever  holds  at  any 
given  time.  Initially,  this  is  the  case,  because  idle  is  initialized  to  true  and  waiting  and 
busy  are  both  initialized  to  false.  Transitions  (3)  and  (4),  the  only  transitions  enabled 
when  idle  is  true  and  waiting  and  busy  are  false,  both  set  idle  to  false;  transition  (3)  also 
sets  waiting  to  true.  Transitions  (1)  and  (5),  the  only  transitions  enabled  when  waiting  is 
true  and  busy  and  idle  are  false,  both  set  waiting  to  false;  transition  (1)  also  sets  busy  to 
true.  Transitions  (2)  and  (6),  the  only  transitions  enabled  when  busy  is  true  and  idle  and 
waiting  are  false,  both  set  busy  to  false;  transition  (2)  also  sets  idle  to  true.  Therefore, 
only  one  of  idle,  waiting  and  busy  ever  holds  at  any  given  time.  This,  combined  with  our 
elimination  of  gone,  proves  the  invariant. 

2.  Only  two  transitions,  (3)  and  (4),  are  enabled  when  idle  holds.  Transition  (3)  sets  idle  to 
false,  and  waiting  to  true.  Transition  (4)  sets  idle  to  false,  establishing  gone  (because  idle, 
waiting  and  busy  are  all  false). 

3.  Only  two  transitions,  (1)  and  (5),  are  enabled  when  waiting  holds.  Transition  (1)  sets 
waiting  to  false,  and  busy  to  true.  Transition  (5)  sets  waiting  to  false,  establishing  gone 
(because  idle,  waiting  and  busy  are  all  false). 

4.  Only  two  transitions,  (2)  and  (6),  are  enabled  when  busy  holds.  Transition  (2)  sets  busy  to 
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false,  and  idle  to  true.  Transition  (6)  sets  busy  to  false,  establishing  gone  (because  idle, 
waiting  and  busy  are  all  false). 

5.  No  transitions  are  enabled  when  gone  holds  (in  addition  to  the  guards  all  being  false,  all 
transitions  that  cause  gone  to  hold  also  contain  a  stop).  Therefore,  gone  is  stable,  since 
there  is  no  way  for  the  system  to  change  its  value. 

Theorem  5.9  (Client  State  Transitions  Progress) 

A  Client  never  stays  in  the  busy  state  forever. 

transient,  busy 


Proof 

Only  two  transitions,  (2)  and  (6),  are  enabled  when  busy  holds.  If  transition  (6)  executes  at  any 
point,  busy  is  falsified.  If  transition  (6)  does  not  execute,  weak  fairness  ensures  that  transition 
(2)  will  execute  at  some  point,  since  transition  (2)  is  the  only  fair  transition  enabled  when  busy 
holds.  Therefore,  busy  is  transient.  □ 

Corollary  5.10  (Client  Busy  State  Progression) 

A  Client  that  is  in  the  busy  state  will  at  some  point  in  the  future  be  in  the  idle  or  gone  state. 

busy  idle  v  gone 


Proof 

This  corollary  follows  immediately  from  Theorem  5.9  and  equation  (5)  of  Theorem  5.8.  □ 

We  now  prove  that  specific  relationships  between  Client  states  and  message  histories  exist 
in  all  executions  of  the  Client  program.  For  brevity,  we  refer  to  (O  lm  tn.mbox  =  “requestin’’), 
the  sequence  of  messages  sent  to  mailboxes  named  “requestln,”  as  requestOut,  and  (O  lm 
m.mbox  =  “releaseln”),  the  sequence  of  messages  sent  to  mailboxes  named  “releaseln,”  as 
releaseOut.  We  also  define  the  following  predicates  that  will  be  used  in  the  proofs  of  these 
relationships: 


Pidie  =  idle  A  requestOut. len  =  tokenln.cnt  =  releaseOut .len 
Pwaiting  =  waiting  a  requestOut. len  -  1  =  tokenln.cnt  =  releaseOut  .len 
Pbusy  =  requestOut  .len  =  tokenln.cnt  =  releaseOut  .len  +  1 
Pgone  =  requestOut  .len  =  releaseOut  .len 
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Lemma  5.11  (Client  Message  Histories— Idle/Waiting/Gone) 

Assume  a  Client  in  the  idle  state  has  received  exactly  as  many  tokens  as  it  has  sent  requests  and 
has  sent  exactly  as  many  releases  as  it  has  sent  requests.  When  that  Client  makes  a  transition 
to  the  waiting  state  from  the  idle  state,  it  will  have  received  exactly  one  fewer  token  than  it  has 
sent  requests  and  sent  exactly  as  many  releases  as  it  has  received  tokens.  In  addition,  when  that 
Client  makes  a  transition  to  the  gone  state  from  the  idle  state,  it  will  have  sent  exactly  as  many 
releases  as  it  has  sent  requests. 


P idle  next  P idle  V  P waiting  V  Pgone 


Proof 

Assume  Pidie,  and  therefore  idle,  holds  in  the  current  state.  From  Theorem  5.8,  we  know  that  if 
idle  holds,  then  exactly  one  of  idle,  waiting  or  gone  will  hold  in  the  next  state. 

If  idle  holds  in  the  next  state,  we  know  that  P^ie  holds  in  the  next  state,  because  there  are 
no  transitions  that  preserve  idle  while  changing  the  length  of  an  outbox  history  or  the  received 
message  index  of  an  inbox. 

If  waiting  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next 
state  is  transition  (3),  because  by  inspection  it  is  the  only  transition  enabled  when  idle  holds 
that  causes  waiting  to  hold  as  part  of  its  postcondition.  P^ie  tells  us  that  requestOut.len  = 
tokenln.len  =  releaseOut.len  in  the  current  state.  Transition  (3)  sends  a  message  to  an  inbox 
named  “requestln,”  increasing  requestOut.len  by  1,  and  does  not  change  any  other  mailbox 
states.  Therefore,  requestOut.len  -  1  =  tokenln.cnt  =  releaseOut.len  must  hold  in  the  next 
state.  The  conjunction  of  this  and  waiting  is  exactly  PWaiting- 

If  gone  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next  state  is 
transition  (4),  because  by  inspection  it  is  the  only  transition  enabled  when  idle  holds  that  causes 
gone  to  hold  as  part  of  its  postcondition.  Pidie  tells  us  that  requestOut.len  =  releaseOut.len  in 
the  current  state.  Transition  (4)  does  not  change  any  mailbox  states.  Therefore,  requestOut.len 
=  releaseOut.len  must  hold  in  the  next  state.  The  conjunction  of  this  and  gone  is  exactly  Pgone- 

□ 

Lemma  5.12  (Client  Message  Histories— Waiting/Busy/Gone) 

Assume  a  Client  in  the  waiting  state  has  received  exactly  one  fewer  token  than  it  has  sent  requests 
and  sent  exactly  as  many  releases  as  it  has  received  tokens.  When  that  Client  makes  a  transition 
to  the  busy  state  from  the  waiting  state,  it  will  have  received  exactly  as  many  tokens  as  it  has 
sent  requests  and  sent  exactly  one  fewer  release  than  it  has  received  tokens.  In  addition,  when 
that  Client  makes  a  transition  to  the  gone  state  from  the  waiting  state,  it  will  have  sent  exactly 
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as  many  releases  as  it  has  sent  requests. 

P waiting  next  P waiting  V  Pbusy  V  P gone 


Proof 

Assume  Pwaitmg,  and  therefore  waiting,  holds  in  the  current  state.  From  Theorem  5.8,  we  know 
that  if  waiting  holds,  then  exactly  one  of  waiting,  busy  or  gone  will  hold  in  the  next  state. 

If  waiting  holds  in  the  next  state,  we  know  that  Pwamng  holds  in  the  next  state,  because  there 
are  no  transitions  that  preserve  waiting  while  changing  the  length  of  an  outbox  history  or  the 
received  message  index  of  an  inbox. 

If  busy  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next  state 
is  transition  (1),  because  by  inspection  it  is  the  only  transition  enabled  when  waiting  holds  that 
causes  busy  to  hold  as  part  of  its  postcondition.  Pwaitmg  tells  us  that  requestOut.len  -  1  = 
tokenln.cnt  =  releaseOut.len  in  the  current  state.  Transition  (1)  advances  tokenln,  increasing 
tokenln.cnt  by  1,  and  does  not  change  any  other  mailbox  states.  Therefore,  requestOut.len  = 
tokenln.cnt  =  releaseOut.len  +  1  must  hold  in  the  next  state.  The  conjunction  of  this  and  busy 
is  exactly  Pbusy 

If  gone  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next  state 
is  transition  (5),  because  by  inspection  it  is  the  only  transition  enabled  when  waiting  holds 
that  causes  gone  to  hold  as  part  of  its  postcondition.  Pwaitmg  tells  us  that  requestOut.len  - 
1  =  tokenln.cnt  =  releaseOut.len  in  the  current  state.  Transition  (5)  sends  a  message  to  an 
inbox  named  “releaseln,”  increasing  releaseOut.len  by  1,  and  does  not  change  any  other  mailbox 
states.  Therefore,  requestOut.len  =  releaseOut.len  must  hold  in  the  next  state.  The  conjunction 
of  this  and  gone  is  exactly  Pgone ■  □ 

Lemma  5.13  (Client  Message  Histories— Busy/Idle/Gone) 

Assume  a  Client  in  the  busy  state  has  received  exactly  as  many  tokens  as  it  has  sent  requests  and 
sent  exactly  one  fewer  release  than  it  has  received  tokens.  When  that  Client  makes  a  transition 
to  the  idle  state  from  the  busy  state,  it  will  have  received  exactly  as  many  tokens  as  it  has  sent 
requests  and  sent  exactly  as  many  releases  as  it  has  received  tokens.  In  addition,  when  that 
Client  makes  a  transition  to  the  gone  state  from  the  busy  state,  it  will  have  sent  exactly  as  many 
releases  as  it  has  sent  requests. 


Pbusy  next  Pbusy  V  Pwaiting  V  Pgone 
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Proof 

Assume  Pbusy,  and  therefore  busy,  holds  in  the  current  state.  From  Theorem  5.8,  we  know  that 
if  busy  holds,  then  exactly  one  of  busy,  idle  or  gone  will  hold  in  the  next  state. 

If  busy  holds  in  the  next  state,  we  know  that  Pbusy  holds  in  the  next  state,  because  there 
are  no  transitions  that  preserve  busy  while  changing  the  length  of  an  outbox  history  or  the 
received  message  index  of  an  inbox. 

If  idle  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next  state 
is  transition  (2),  because  by  inspection  it  is  the  only  transition  enabled  when  busy  holds  that 
causes  idle  to  hold  as  part  of  its  postcondition.  Pbusy  tells  us  that  requestOut.len  =  tokenln.cnt  = 
releaseOut. len  +  1  in  the  current  state.  Transition  (2)  sends  a  message  to  an  inbox  named  “relea- 
seln,”  increasing  releaseOut.len  by  1,  and  does  not  change  any  other  mailbox  states.  Therefore, 
requestOut.len  =  tokenln.cnt  =  releaseOut. len  must  hold  in  the  next  state.  The  conjunction  of 
this  and  idle  is  exactly  P^ie- 

If  gone  holds  in  the  next  state,  we  know  that  the  transition  that  brings  about  the  next 
state  is  transition  (6),  because  by  inspection  it  is  the  only  transition  enabled  when  busy  holds 
that  causes  gone  to  hold  as  part  of  its  postcondition.  Pbusy  tells  us  that  requestOut.len  = 
tokenln.cnt  =  releaseOut.len  +  1  in  the  current  state.  Transition  (6)  sends  a  message  to  an 
inbox  named  “releaseln,”  increasing  releaseOut.len  by  1,  and  does  not  change  any  other  mailbox 
states.  Therefore,  requestOut.len  =  releaseOut.len  must  hold  in  the  next  state.  The  conjunction 
of  this  and  gone  is  exactly  Pgone-  □ 

Theorem  5.14  (Client  States  and  Message  Histories) 

A  Client  in  the  idle  state  has  received  exactly  as  many  tokens  as  it  has  sent  requests  and  has 
sent  exactly  as  many  releases  as  it  has  received  tokens.  A  Client  in  the  waiting  state  has  received 
exactly  one  fewer  token  than  it  has  sent  requests  and  sent  exactly  as  many  releases  as  it  has 
received  tokens.  A  Client  in  the  busy  state  has  received  exactly  as  many  tokens  as  it  has  sent 
requests  and  sent  exactly  one  fewer  release  than  it  has  received  tokens.  A  Client  in  the  gone  state 
has  sent  exactly  as  many  releases  as  it  has  sent  requests. 

invariant. ( ( idle  =>  Pidie)  a  ( waiting  =>  P waiting)  a  ( busy  =>  Pbusy)  A  (gone  =>  Pgone)) 


Proof 

Initially,  the  Client  is  in  a  state  where  P^ie  holds:  idle  is  initialized  to  true,  and  all  mailboxes  are 
initially  empty.  By  induction,  Lemmas  5.11,  5.12  and  5.13  tell  us  that  this  invariant  holds  for 
all  states  if  it  holds  for  the  initial  state,  since  the  combination  of  those  theorems  shows  that 
all  transitions  from  state  X  where  P x  holds  are  to  state  Y  where  Py  holds,  where  X  and  Y  can 
each  be  one  of  idle,  busy,  waiting  or  gone,  subject  to  the  permissible  state  transitions  shown 
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in  Theorem  5.8.  □ 

Corollary  5.15  (Client  Tokens/Releases  Safety) 

The  difference  between  the  number  of  tokens  a  Client  has  received  and  the  number  of  releases 
it  has  sent  is  always  between  -1  and  1,  inclusive. 


invariant.  (- 1  <  tokenln. cnt  -  releaseOut .len  <  1) 


Proof 

This  corollary  follows  immediately  from  Theorem  5.14.  □ 

Corollary  5.16  (Client  Tokens/Releases  Progress) 

If  a  Client  has  received  more  tokens  than  it  has  sent  releases,  at  some  point  it  will  have  sent 
exactly  as  many  releases  as  it  has  received  tokens. 


tokenln.cnt  >  releaseOut  .len  tokenln.  cnt  =  releaseOut  .len 


Proof 

This  corollary  follows  immediately  from  Corollary  5.10  and  Theorem  5.14.  □ 

We  have  now  shown  all  the  behavior  of  the  Client  in  isolation  that  we  will  need  to  use  in  our 
proof  of  correctness  for  the  composed  system. 

5.4  The  Composed  System 

The  composed  system  contains  the  Resource  program  (Specification  5.1),  the  Client  program 
(Specification  5.2),  and  a  small  initial  program  called  Generator  that  takes  care  of  creating  the 
Resource  and  the  Clients.  We  first  prove  some  properties  about  this  Generator  program,  and 
then  prove  the  correctness  of  the  composed  system. 

5.4.1  The  Generator  Program 

The  Generator  program  is  responsible  for  creating  a  Resource  process  in  the  system,  as  well 
as  for  creating  Client  processes  for  that  Resource.  We  prove  that  the  Generator  is  well-formed, 
and  that  its  reference  to  the  Resource  is  stable  (that  is,  that  its  resource  state  variable  always 
refers  to  the  same  process  in  the  system). 

Theorem  5.17  (Generator  Well-Formedness) 

The  Generator  program  is  well-formed. 
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system  SingleResourceMutualExclusion 

initial-program  Generator 
declare 

resource:  process 
initially 

resource  =  new  Resource 

fair-transition 

(1)  p:  p'  =  new  Client(resource) 


end 

program  Resource 
program  Client(resource:  process) 
end 


Specification  5.3:  The  SingleResourceMutualExclusion  system 


Proof 

We  prove  that  the  Generator  program  is  well-formed  by  showing  that  its  always-section,  initially- 
section,  and  transition-sections  are  well-formed: 

always-section  The  Generator  program  has  no  always-section,  so  we  need  not  show  that  its 
always-section  is  well-formed. 

initially-section  The  initially-section  of  the  Generator  program  instantiates  a  Resource  pro¬ 
cess.  This  is  not  an  infinitely  recursive  instantiation,  since  the  Resource  process  is  well-formed 
(as  shown  in  Theorem  5.1).  Moreover,  it  is  satishable.  Therefore,  the  Generator  program’s 
initially-section  is  well-formed. 

transition-sections  For  each  transition,  we  must  demonstrate  that  its  postcondition  is  always 
satishable  if  its  precondition  holds.  There  is  only  one  transition  in  the  Generator  program, 
which  is  an  instantiation  of  a  Client  process.  This  is  always  satishable  (since  the  Client  process  is 
well-formed,  as  shown  in  Theorem  5.7).  Therefore,  the  Generator  program’s  transition-sections 
are  well-formed. 

Since  all  sections  of  the  Generator  program  are  well-formed,  the  entire  program  is  well- 


formed. 


□ 


99 


Theorem  5.18  (Generator  Resource  Reference  Stability) 

Once  a  process  is  instantiated  and  a  reference  to  that  process  is  assigned  to  resource  in  a  Gen¬ 
erator  process,  resource  refers  to  that  process  forever: 

(Vp  >  stable. (resource  =  p)) 


Proof 

Initially,  resource  is  assigned  to  be  a  reference  to  a  new  instance  of  the  Resource  program.  No 
transition  in  the  Resource  program  modifies  the  resource  reference.  Therefore,  resource  refers 
to  the  same  instance  of  the  Resource  program  forever.  □ 

We  have  now  shown  all  the  behavior  of  the  Generator  program  in  isolation  that  we  will  need 
to  use  in  our  proof  of  correctness  for  the  composed  system. 

5.4.2  Proof  of  Correctness 

We  now  show  that  the  entire  system  implements  a  single  resource  mutual  exclusion  algorithm, 
by  proving  several  theorems  about  the  system  using  the  properties  we  have  already  proven 
about  the  Generator,  Resource  and  Client  programs  in  isolation. 

Theorem  5.19  (Generator  And  Resource  Uniqueness/Stability) 

There  is  exactly  one  Generator  process  and  exactly  one  Resource  process  in  the  SingleResource- 
MutualExclusion  system,  and  these  processes  never  stop. 

Proof 

We  need  to  prove  that  a  single  Generator  process  is  created  in  every  possible  execution  of  the 
system,  that  a  single  Resource  process  is  created  in  every  possible  execution  of  the  system,  that 
it  is  impossible  for  any  other  Generator  or  Resource  processes  to  be  created,  and  that  these 
processes  never  stop. 

Generator  is  the  initial  program  of  the  system,  so  a  single  instance  of  Generator  is  created 
at  system  initialization  time.  Theorem  5.17  shows  that  the  Generator  program  is  well-formed, 
and  by  inspection  it  does  not  contain  a  stop  statement.  Therefore,  in  accordance  with  Dy¬ 
namic  UNITY  execution  semantics,  it  runs  forever.  Also  by  inspection,  no  program  contains  a 
statement  that  instantiates  a  Generator  process.  Therefore,  no  other  Generator  process  is  ever 
instantiated  during  the  execution  of  the  system. 

A  single  Resource  process  is  instantiated  by  the  initially-section  of  the  Generator  program. 
By  inspection,  there  are  no  other  statements  in  any  program  that  instantiate  a  Resource  pro¬ 
cess.  We  have  already  shown  that  exactly  one  Generator  process  is  created.  Therefore,  exactly 
one  Resource  process  is  created  during  the  Generator  process’s  construction.  Theorem  5.1 


100 


shows  that  the  Resource  program  is  well-formed,  and  by  inspection  it  does  not  contain  a  stop 
statement.  Therefore,  in  accordance  with  Dynamic  UNITY  execution  semantics,  it  runs  forever. 

□ 

Theorem  5.20  (Client  Resource  Reference  Uniqueness) 

All  Client  processes  in  the  SingleResourceMutualExclusion  system  have  references  to  the  same 
Resource  process. 

invariant.  ((\/r  \  r  G  T  a  r  =  resource  \>{\/c,q\cGTAc  =  Client(q)  >  q  =  r))) 


Proof 

By  inspection,  the  only  statement  in  any  program  that  instantiates  a  Client  process  is  part 
of  transition  (1)  of  the  Generator  program.  Theorem  5.19  shows  that  there  is  exactly  one 
Resource  process  in  the  system,  so  the  quantification  always  ranges  over  exactly  one  Resource 
process,  and  also  shows  that  the  Resource  process  is  created  by  the  one  Generator  process  in 
the  system.  Theorem  5.18  shows  that  the  Generator’s  resource  variable  always  refers  to  this 
Resource  process.  Therefore,  all  Client  processes  created  by  the  Generator  program  have  a 
reference  to  the  same  Resource  process  as  their  resource  parameter.  □ 

In  the  following  theorems,  we  refer  to  the  single  Resource  process  in  the  SingleResource¬ 
MutualExclusion  system  as  R.  For  brevity,  we  refer  to  (Op  \m  m.mbox  =  “requestin’’),  the 
sequence  of  messages  sent  to  mailboxes  named  “requestin’’  by  process  p,  as  p .requestOut,  and 
(Op  1  m  m.mbox  =  “releaseln”),  the  sequence  of  messages  sent  to  mailboxes  named  “releaseln” 
by  process  p,  as  p.releaseOut. 

Theorem  5.21  (Messaging  Connections) 

For  every  Client  process  c,  the  message  histories  of  R.requestln  filtered  by  proc  =  c  and  R.release- 
In  filtered  by  proc  =  c  follow  the  message  histories  of  c.requestOut  and  c.releaseOut  respectively. 
For  every  Client  process  c,  the  message  history  of  c.tokenln  follows  the  message  history  of  0R 
filtered  by  proc  =  c. 

invariant. (( V c  \c  G  T  A  c  =  Client(R)  > 

( R.requestln  \m  m.proc  =  c).msg  follows  c. requestOut. msg  a 
(R. releaseln  lm  m.proc  =  c).msg  follows  c.releaseOut. msg  a 
c .tokenln.msg  follows  ( 0R  1  m  m.proc  =  c).msg) 


Proof 

By  inspection,  all  messages  sent  by  a  Client  are  sent  to  the  inbox  named  “requestin’’  associated 
with  the  Resource  process  to  which  the  Client  has  a  reference.  Theorem  5.20  says  that  this 
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Resource  process  is  R,  for  all  Client  processes.  Also  by  inspection,  the  “requestin’’  inbox  of  R  is 
always  R.requestln.  It  immediately  follows  from  the  Channel  Theorem  that  R.requestln  filtered 
by  proc  =  c  follows  c.requestOut.  By  symmetry,  the  same  is  true  for  the  release  outbox/inbox 
pair. 

By  inspection,  all  messages  sent  by  R  are  sent  to  the  inbox  named  “tokenin’’  associated  with 
the  destination  process.  If  the  destination  process  is  a  Client  instantiation,  the  “tokenin’’  inbox 
is  always  the  tokenln  variable  of  that  process;  if  the  destination  process  is  not  a  Client  instan¬ 
tiation,  it  has  no  bearing  on  this  theorem.  It  immediately  follows  from  the  channel  theorem 
(Theorem  3.11)  that,  for  all  Client  processes,  the  tokenln  message  history  follows  R’s  outgoing 
message  sequence  filtered  by  proc  =  c.  □ 

We  now  prove  system  safety,  by  showing  that  there  is  exactly  one  live  token  in  the  system 
at  all  times.  The  number  of  live  tokens  in  the  system  is  defined  as  the  sum  of  the  number  of 
tokens  held  by  the  Resource,  the  number  of  tokens  held  by  Clients,  the  number  of  live  tokens 
in  transit  from  Clients  to  the  Resource,  and  the  number  of  live  tokens  in  transit  from  the 
Resource  to  Clients.  A  live  token  in  transit  from  a  Client  to  a  Resource  is  a  release  message 
whose  corresponding  request  that  has  been  handled  by  the  Resource.  If  there  are  two  release 
messages  in  transit  from  a  Client  to  the  Resource,  there  is  only  one  live  token  in  transit  from 
that  Client  to  the  Resource  (because,  as  we  will  see,  message  histories  dictate  that  there  also 
be  an  unhandled  request  message  in  transit  from  that  Client  to  the  Resource).  A  live  token  in 
transit  from  a  Resource  to  a  Client  is  a  token  message  whose  destination  Client  is  not  in  the 
gone  state.  Since  a  Client  in  the  gone  state  never  receives  any  messages,  a  token  message  sent 
to  such  a  Client  will  never  be  received  and  therefore  does  not  play  a  further  role  in  the  system. 

For  use  in  our  safety  proof,  we  define  the  following  quantities  (some  of  which  are  parameter¬ 
ized  by  a  Client  c)  that  represent  the  numbers  of  tokens  in  transit  in  the  system  in  accordance 
with  the  above  definitions.  Rout  is  the  number  of  live  tokens  in  transit  from  the  Resource  that 
are  still  in  the  Resource’s  outbox;  C!n(c)  is  the  number  of  live  tokens  in  transit  from  the  Re¬ 
source  that  are  in  Client  c’s  tokenln  inbox;  Rm(c)  is  the  number  of  tokens  in  transit  from  Client 
c  to  the  Resource  that  are  either  in  the  Resource’s  releaseln  inbox  or  in  its  releases  multiset; 
and  Cout(c)  is  the  number  of  tokens  in  transit  from  Client  c  to  the  Resource  that  are  still  in  the 
Client’s  outbox.  For  brevity,  from  this  point  forward,  we  denote  the  set  of  clients  in  the  system 
(that  is,  the  set  of  all  processes  of  type  Client(R))  by  CS: 

Rout  =  (#i  |  0Rcnt  <  i  <  (9R.len[>  -*QR [i]. proc. gone) 


Cm(c)  =  (Z.d  |  d  =  c  a  -■ d.gone  i>  d.tokenln.len  -  d.tokenln.cnt) 
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Rinic  *  R. current)  = 

( #i  |  R.releaseln. cnt  <  i  <  R.releaseln.len  >  R.releaseln[i], proc  =  c)  - 
(#i  |  R.requestln.cnt  <  i  <  R.requestln.len  \>  R.requestln[i], proc  =  c)  + 

< #p  |  p  G  R.releases  >  p  =  c) 

R,„(c  =  R. current)  = 

(#i  |  R.releaseln. cnt  <  i  <  R.releaseln.len  >  l?.reZeflse/n[i].proc  =  c)  + 

{#p  |  p  e  R.releases  >  p  =  c) 

Coutic  *  R. current)  = 

(c.releaseOut. len-  c.releaseOut. cnt)  -  (c .requestOut .len  -  c.requestOut. cnt) 

Coutic  =  R. current)  =  c .releaseOut .len  -  c.releaseOut. cnt 

The  actual  numbers  of  live  tokens  in  the  system  held  by  the  Resource,  the  Clients,  and  in 
transit,  are  defined  as  follows  (note  that  we  do  not  allow  there  to  be  negative  live  tokens  in  the 
system,  and  negative  tokens  in  transit  are  not  included  in  the  sums): 

LTresource  =  <#r  |  Y  =  R  E>  R.Z'd/e) 

LT clients  =  {#c  \  c  G  CS  \>  C .busy) 


LTtransit  =  Rout  +  (Sc  |  c  G  CS  a  c  *  R. current  >  C,-„(c)  +  max(Couf(c)  +  Rin(c),0))  + 

Cm(R.current)  +  (#c  |  c  =  R. current  >  1  <  R,„(c)  +  Cout(c)  <  2) 

We  now  use  these  equations  to  define  the  following  predicates,  which  describe  the  possible 
states  of  the  tokens  in  the  system: 

NOTBUSY  =  (\/c  \  c  G  CS  c>  ^c.busy) 

BUSY(c)  =  c.busy  A  (Vd  |deC5Ad*ct>  -> d.busy ) 


Presource  —  (Vc  |  C  G  C5  l>  1  <  Rjn(c)  +  Cout(c)  —  0)  A 


Rouf  =  0a(Vc|cgC5o  Cin(c)  =  0)  a  R.idle  a  NOTBUSY 
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Ptoclient  =  (Vc|ceCSi>-l<  Rin(c)  +  Cout(c)  <  0)  a  Rout  +  Cjn{R. current)  =  1  A 

Rout  +  (2c  |  c  e  CS  >  Cm(c))  =  1  a  R.busy  a  NOTBUSY 


P dient  =  <  V C  |  C  G  CS  >  -1  <  Rm(c)  +  Cout(c)  <  0)  A  Rouf  =  0  A 

(Vc  |  c  e  CS  >  C/n(c)  =  0)  a  R.busy  a  BUSY  {R. current) 

Ptoresource  =  1  <  Rin(R. current)  +  Cout(R.current)  <  2  a 

( Vc  |  c  g  CS  a  c  ^  R. current  >  -1  <  R,„(c)  +  C0Uf(c)  <  0)  A 
Rouf  =  0  a  <  Vc  |  c  e  CS  >  Cin(c)  =  0)  a  R.busy  a  NOTBUSY 

Lemma  5.22  (System  State  Transitions— Resource) 

If  the  system  is  in  the  state  where  the  Resource  holds  a  live  token  (PtoresourceA  the  next  state  will  be 
either  the  same,  the  state  where  a  live  token  is  in  transit  to  the  Resource’s  current  Client  (Ptoclient A 
or  the  state  where  a  live  token  is  in  transit  to  the  Resource  from  the  Resource’s  current  Client 

(Ptoresource  A 

Presource  next  Presource  V  Ptoclient  V  Ptoresource 

Proof 

Assume  Presource  holds  in  the  current  state.  We  examine  all  possible  state  transitions  in  the 
system  to  determine  the  possible  next  states. 

Transition  (1)  of  the  Resource  program  may  be  enabled,  since  R.idle  holds  in  the  current 
state.  If  transition  (1)  is  enabled,  then  there  is  a  message  waiting  on  requestln  from  a  particular 
Client  c.  Execution  of  the  transition  reads  this  message,  falsifies  R.idle  by  setting  R.  current  to  c, 
and  sends  a  message  to  c’s  tokenln  inbox.  If  c  is  not  in  the  gone  state,  this  transition  establishes 
Ptoclient  in  the  next  state,  as  follows:  for  all  clients  d,  d  *  c,  -1  <  Rtn(d)  +  Cout(d)  <  0  still 
holds  because  transition  (1)  hasn’t  changed  it.  -1  <  R,-n(c)  +  Cout(c)  <  0  holds,  because  the 
definitions  of  these  terms  for  c  =  R. current  combined  with  the  message  histories  for  a  Client 
that  is  not  in  the  gone  state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem 
5.3)  and  the  messaging  connections  (Theorem  5.21)  imply  that  both  Rj„(c)  and  Cout(c)  are 
equal  to  0.  Rout  +  Cm(R.current)  =  1  holds,  because  this  sum  was  previously  0,  and  Rout  is 
now  1.  Rout  +  (2c  |  c  e  CS  t>  Cm(c ))  =  1  holds,  because  this  sum  was  previously  0  and  Rout 
is  now  1.  R.busy  holds  because  it  is  part  of  the  postcondition  (R. current  is  assigned  a  value), 
and  NOTBUSY  holds  because  the  transition  does  not  change  any  client  states.  The  conjunction 
of  these  is  exactly  Ptoclient ■  If  c  is  in  the  gone  state,  this  transition  establishes  Ptoresource  in 
the  next  state,  as  follows:  R,-„(c)  +  Couf(c)  =  1  holds,  because  the  definitions  of  these  terms 
for  c  =  R. current  combined  with  the  message  histories  for  a  Client  that  is  not  in  the  gone 
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state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem  5.3)  and  the  messaging 
connections  (Theorem  5.21)  imply  that  exactly  one  of  Rm(c)  and  Cout(c)  is  equal  to  1.  For  all 
clients  d,  d  =/=  c,  -1  <  Rm(d)  +  Cout(d)  <  0  holds  because  transition  (1)  hasn’t  changed  it. 
Rout  =  0  holds  because  the  message  that  transition  (1)  sends  doesn’t  contribute  to  Rout  (its 
destination  is  in  the  gone  state),  so  Rout  is  left  unchanged.  (Vc  |  c  e  CS  D>  C,„(c)  =  0)  holds 
because  it  held  in  the  previous  state  and  is  unchanged  by  transition  (1).  R. busy  holds  because 
it  is  part  of  the  postcondition,  and  NOTBUSY  holds  because  the  transition  does  not  change  any 
client  states.  The  conjunction  of  these  is  exactly  Ptoresource- 

Transition  (2)  of  the  Resource  program  is  not  enabled,  because  R.busy  does  not  hold. 

Transition  (3)  of  the  Resource  program  may  be  enabled.  If  it  is  executed,  it  reads  a  message 
from  R.releaseln  and  places  an  entry  in  R. releases.  This  does  not  change  R,„(c)  for  any  c, 
because  it  is  subtracting  1  from  the  number  of  unread  messages  from  c  while  adding  1  to  the 
number  of  appearances  of  c  in  the  set.  Therefore,  the  system  state  after  transition  (3)  is  still 
Presource- 

Transition  (1)  of  the  Client  program  is  not  enabled  for  any  Client  c,  because  Cifl(c)  =  0  for 
all  c. 

Transitions  (2)  and  (6)  of  the  Client  program  are  not  enabled  for  any  Client  c,  because 
NOTBUSY  holds. 

Transition  (3)  of  the  Client  program  is  enabled  for  Client  c  only  if  c.idle  holds.  It  sends  a 
message  to  R.requestln,  decrementing  Couf(c)  by  1.  Because  c.idle  holds,  and  the  Resource  is 
idle,  we  know  that  Rmic)  +  Cout(c)  =  0.  This  follows  from  the  message  histories  for  a  Client  that 
is  in  the  idle  state  state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem  5.3) 
and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system  state  after  transition  (3) 
is  still  Presource,  but  with  Rin(c)  +  Cout(c )  =  -1. 

Transition  (4)  of  the  Client  program  does  not  send  a  message  or  cause  a  Client  to  enter  the 
busy  State,  SO  it  does  not  falsify  Presource- 

Transition  (5)  of  the  Client  program  is  enabled  for  Client  c  only  if  c. waiting  holds.  It  sends  a 
message  to  R.releaseln,  incrementing  Cout(c)  by  1.  Because  c.waiting  holds,  and  the  Resource 
is  idle,  we  know  that  R!(1(c)  +  Cout(c)  =  -1.  This  follows  from  the  message  histories  for  a  Client 
that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem  5.3) 
and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system  state  after  transition  (3) 
is  still  Presource,  but  with  Rin(c)  +  Cout(c )  =  0. 

If  an  outgoing  message  from  c  is  delivered,  Presource  is  maintained,  since  delivery  of  the 
message  increments  or  decrements  Cout(c)  by  1  and  correspondingly  decrements  or  increments 
Rin(c)  by  1. 
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The  transitions  of  the  Generator  do  not  affect  the  next  property,  since  they  do  not  cause 
any  messages  to  be  sent  or  received  and  all  Clients  created  by  the  Generator  are  initially  idle. 
Therefore,  all  transitions  in  the  system  maintain  the  next  property.  □ 

Lemma  5.23  (System  State  Transitions— To  Client) 

If  the  system  is  in  the  state  where  a  live  token  is  in  transit  to  the  Resource’s  current  Client  (PtociientA 
the  next  state  will  be  either  the  same,  the  state  where  the  Resource’s  current  Client  holds  a  live 
token  (PciientA  or  the  state  where  a  live  token  is  in  transit  to  the  Resource  from  the  Resource's 
current  Client  (Pt0resourcel- 


P toclient  next  P toclient  V  P client  V  P i 


toresource 


Proof 

Assume  Ptochent  holds  in  the  current  state.  We  examine  all  possible  state  transitions  in  the 
system  to  determine  the  possible  next  states. 

Transition  (1)  of  the  Resource  program  is  not  enabled,  because  R. busy  holds. 

Transition  (2)  of  the  Resource  program  is  not  enabled,  because  we  must  have  Rm(R- current) 
=  0  to  satisfy  the  Rm(R. current)  +  Cout(R- current)  <  0  in  Ptochent,  and  this  means  that  there  are 
no  instances  of  R. current  in  the  releases  multiset. 

Transition  (3)  of  the  Resource  program  may  be  enabled.  If  it  is  executed,  it  reads  a  message 
from  R.releaseln  and  places  an  entry  in  R. releases.  This  does  not  change  Rf„(c)  for  any  c, 
because  it  is  subtracting  1  from  the  number  of  unread  messages  from  c  while  adding  1  to  the 
number  of  appearances  of  c  in  the  set.  Therefore,  the  system  state  after  transition  (3)  is  still 
P  toclient  ■ 

A  message  may  be  delivered  from  the  Resource’s  outbox  to  its  destination  inbox.  Assume 
the  delivered  message  is  destined  for  Client  c.  If  c  is  in  the  gone  state,  neither  Rout  nor  C/n(c) 
is  changed  (by  definition);  if  c  is  not  in  the  gone  state,  Rout  is  decremented  (to  0)  and  C,„ ( c )  is 
incremented  (to  1),  maintaining  Ptoclient- 

Transition  (1)  of  the  Client  program  may  be  enabled  for  c  =  R. current,  but  will  not  be 
enabled  for  any  other  Client  because  C!n(c  *  R. current)  =  0.  This  transition  reads  a  message 
from  tokenln,  which  decrements  C,n(c)  by  1  and  makes  Rout  =  0  and  C/„ ( c )  =  0.  After  the 
transition,  therefore,  we  have  Rout  =  0  and  (Vc  |  c  e  CS  >  C,-n(c)  =  0).  The  transition  does 
not  change  c.requestOut  or  c.releaseOut  or  set  the  state  of  c  to  gone,  so  after  its  execution 
(Vc  [  c  e  C5>  -1  <  Rm(c)  +  Cout (c)  <  0)  still  holds.  R.busy  still  holds,  because  the  transition 
does  not  affect  it.  Client  c  is  in  the  busy  state  after  the  transition,  so  BUSY(c)  holds  because 
the  states  of  the  other  Clients,  all  of  which  were  idle,  do  not  change.  The  conjunction  of  these 
is  exactly  Patent- 
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Transitions  (2)  and  (6)  of  the  Client  program  are  not  enabled  for  any  Client  c,  because 
NOTBUSY  holds. 

Transition  (3)  of  the  Client  program  is  enabled  for  Client  c  only  if  c.idle  holds.  It  sends  a 
message  to  R.requestln,  decrementing  Cout(c)  by  1.  Because  c.idle  holds,  and  the  Resource  is 
busy,  we  know  that  R,„(c)  +  Coui(c)  =  0  for  all  c  =r  R. current.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  We  also  know,  from 
the  same  message  histories  and  connections,  that  R. current  must  be  in  either  the  waiting  or 
gone  state,  so  its  transition  (3)  is  not  enabled.  Therefore,  the  system  state  after  transition  (3) 
is  still  P tochent ,  but  with  Rmic)  +  Cout(c)  =  -1. 

Transition  (4)  of  the  Client  program  does  not  send  a  message  or  cause  a  Client  to  enter  the 
busy  state,  so  it  does  not  falsify  Ptociient- 

Transition  (5)  of  the  Client  program  is  enabled  for  Client  c  only  if  c. waiting  holds.  It  sends  a 
message  to  R.releaseln,  incrementing  Cout(c)  by  1.  Because  c. waiting  holds,  and  the  Resource  is 
busy,  we  know  that  R!n(c)  +  C„ui  (c)  =  -1  for  all  c  =/=  R. current.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system 
state  after  transition  (5)  is  still  Ptociient,  but  with  Rm(c)  +  Cout  (c)  =  0,  if  c  R. current.  If  c  = 
R. current,  we  know  from  the  same  message  histories  and  connections  that  Rm(c)  +  Cout(c)  = 
0.  The  sending  of  the  message  to  R.releaseOut  increases  this  sum  to  1.  The  transition  also 
establishes  Rout  =  0  a  (Vc  |  c  e  CS  \>  Cm(c )  =  0),  because  it  causes  the  Client  to  transition 
to  the  gone  state,  making  that  sum  equal  to  0  for  all  Clients  (it  was  previously  0  for  all  Clients 
other  than  R. current).  The  conjunction  of  these  and  the  parts  of  Ptociient  that  are  not  changed 
by  the  transition  is  exactly  Ptoresource- 

One  or  more  messages  from  any  Client  except  R. current  to  the  Resource  may  be  delivered. 
This  follows  from  the  message  histories  for  a  Client  that  is  in  the  waiting  state  (Theorem  5.14), 
the  message  histories  for  the  Resource  (Theorem  5.3)  and  the  messaging  connections  (Theo¬ 
rem  5.21).  If  this  occurs  message  is  delivered,  Ptociient  is  maintained,  since  it  increments  or 
decrements  Couf(c)  and  correspondingly  decrements  or  increments  Rin(c). 

The  transitions  of  the  Generator  do  not  affect  the  next  property,  since  they  do  not  cause 
any  messages  to  be  sent  or  received  and  all  Clients  created  by  the  Generator  are  initially  idle. 

Therefore,  all  transitions  in  the  system  maintain  the  next  property.  □ 

Lemma  5.24  (System  State  Transitions— Client) 

If  the  system  is  in  a  state  where  the  Resource’s  current  Client  holds  a  live  token  (PcuentA  the  next 
state  will  be  either  the  same  or  the  state  where  a  live  token  is  in  transit  to  the  Resource  from  the 
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Resource’s  current  Client  (Ptoresourcel- 


P client  next  P client  V  P 


toresource 


Proof 

Assume  Pciient  holds  in  the  current  state.  We  examine  all  possible  state  transitions  in  the  system 
to  determine  the  possible  next  states. 

Transition  (1)  of  the  Resource  program  is  not  enabled,  because  R. busy  holds. 

Transition  (2)  of  the  Resource  program  is  not  enabled,  because  we  must  have  Rjn(R.  current) 
=  0  to  satisfy  the  Ri„(R. current)  +  Cout(R .current)  <  0  in  Pciient,  and  this  means  that  there  are 
no  instances  of  R. current  in  the  releases  multiset. 

Transition  (3)  of  the  Resource  program  may  be  enabled.  If  it  is  executed,  it  reads  a  message 
from  R.releaseln  and  places  an  entry  in  R. releases.  This  does  not  change  R,„(c)  for  any  c.  If 
c  =/=  R. current,  it  subtracts  1  from  the  number  of  unread  messages  from  c  while  adding  1  to 
the  number  of  appearances  of  c  in  the  set;  if  c  =  R. current,  it  is  not  possible  that  there  was 
a  message  from  c  on  releaseln,  because  c  is  in  the  busy  state.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  busy  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system 
state  after  transition  (3)  is  still  Pciient- 

Transition  (1)  of  the  Client  program  is  not  enabled  for  any  Client,  because  ( Vc  |  c  e  CS  o 
Cm(c)  =  0)  holds. 

Transition  (2)  of  the  Client  program  is  enabled  for  R. current,  but  not  for  any  other  Client, 
since  BUSY(R. current)  holds.  Execution  of  this  transition  falsifies  R. current. busy,  established 
R.current.idle,  and  sends  a  message  to  from  R. current  to  R.releaseln.  We  know,  from  the  mes¬ 
sage  histories  for  a  Client  that  is  in  the  busy  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21),  that  Rin(R. current)  + 
C out (R .current)  =  0  holds  before  execution  of  the  transition;  the  sending  of  the  message  to 
R.releaseln  increases  this  sum  to  1.  The  transition  also  establishes  NOTBUSY,  because  it  puts 
R.  current  into  the  idle  state.  The  conjunction  of  these  and  the  parts  of  Pciient  that  are  unchanged 
by  execution  of  transition  (2)  is  exactly  Ptoresource- 

Transition  (3)  of  the  Client  program  is  enabled  for  Client  c  only  if  c.idle  holds.  It  sends  a 
message  to  R.requestln,  decrementing  C0Iif(c)  by  1.  Because  c.idle  holds,  and  the  Resource  is 
busy,  we  know  that  Rm(c)  +  Cout(c)  =  0  for  all  c  *  R. current.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  We  also  know  that 
R. current  is  in  the  busy  state,  since  BUSY (R. current)  holds,  so  its  transition  (3)  is  not  enabled. 


108 


Therefore,  the  system  state  after  transition  (3)  is  still  Pcuent,  but  with  Rmic)  +  Cout  (c)  =  -1. 

Transition  (4)  of  the  Client  program  is  enabled  only  for  Clients  in  the  idle  state  (and  is 
therefore  disabled  for  R. current).  It  does  not  send  a  message  or  cause  a  Client  to  enter  the 
busy  state,  so  it  does  not  falsify  Pdient- 

Transition  (5)  of  the  Client  program  is  enabled  for  Client  c  only  if  c. waiting  holds.  It  sends  a 
message  to  R.releaseln ,  incrementing  Cout(c)  by  1.  Because  c.  waiting  holds,  and  the  Resource  is 
busy,  we  know  that  R!n(c)  +  Cou,  (c)  =  -1  for  all  c  =t=  R. current.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system 
state  after  transition  (5)  is  still  Pciient,  but  with  R;„(c)  +  C0Uf(c)  =  0,  if  c  =£  R. current.  We  know 
that  R. current  is  in  the  busy  state,  since  BUSY  (R.  current)  holds.  Therefore,  its  transition  (5)  is 
not  enabled. 

One  or  more  messages  from  any  Client  except  R. current  to  the  Resource  may  be  delivered. 
This  follows  from  the  message  histories  for  a  Client  that  is  in  the  waiting  state  (Theorem  5.14), 
the  message  histories  for  the  Resource  (Theorem  5.3)  and  the  messaging  connections  (Theo¬ 
rem  5.21).  If  this  occurs  message  is  delivered,  Ptociient  is  maintained,  since  it  increments  or 
decrements  Cout(c)  and  correspondingly  decrements  or  increments  R ( c ) . 

The  transitions  of  the  Generator  do  not  affect  the  next  property,  since  they  do  not  cause 
any  messages  to  be  sent  or  received  and  all  Clients  created  by  the  Generator  are  initially  idle. 

Therefore,  all  transitions  in  the  system  maintain  the  next  property.  □ 

Lemma  5.25  (System  State  Transitions— To  Resource) 

If  the  system  is  in  a  state  where  a  live  token  is  in  transit  to  the  Resource  from  the  Resource's 
current  Client  (PtoresourceA  the  next  state  will  be  either  the  same  or  the  state  where  the  Resource 
holds  a  live  token  (PresourceA 


Ptoresource  next  Ptoresource  V  P 


resource 


Proof 

Assume  Ptoresource  holds  in  the  current  state.  We  examine  all  possible  state  transitions  in  the 
system  to  determine  the  possible  next  states. 

Transition  (1)  of  the  Resource  program  is  not  enabled,  because  R. busy  holds. 

Transition  (2)  of  the  Resource  program  is  enabled  only  if  (#p  \  p  e  releases  \>p  =  R. current) 
>  1.  Execution  of  transition  (2)  removes  an  instance  of  R. current  from  releases ,  and  sets 
R. current  to  _L.  This  establishes  (Vc  |  c  e  CS  >  -1  <  Rin(c)  +  Couf(c)  <  0),  as  follows:  for  all 
c  *  R. current,  the  inequality  already  held,  and  for  c  =  R.currentwe  had  1  <  Rjn(c)  +  Coui  (c)  <  2. 
This  means  that  there  were  either  1  or  2  release  messages  in  transit  from  R. current  to  the  Re- 
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source,  and  after  execution  of  transition  (2)  there  are  0  or  1  release  messages  in  transit  from 
that  Client.  From  the  message  histories  for  a  Client  that  is  not  in  the  busy  state  (Theorem  5.14), 
the  message  histories  for  the  Resource  (Theorem  5.3)  and  the  messaging  connections  (Theo¬ 
rem  5.21),  we  know  that  the  maximum  number  of  request  messages  in  transit  from  a  non-busy 
Client  to  the  Resource  is  1,  and  that  if  2  release  messages  are  in  transit  from  a  non-busy  Client, 
then  1  request  message  is  in  transit  from  that  Client  as  well.  The  definitions  of  Rm(c)  and 
Cout(c)  for  c  =  R. current  differ  from  those  for  c  =/=  R. current  only  in  that  the  former  subtract 
the  number  of  request  messages  from  the  latter.  Therefore,  we  have  -1  <  Rm(c)  +  C0ut(c)  <  0 
for  all  c  after  execution  of  transition  (2).  Transition  (2)  also  establishes  R.idle.  The  conjunction 
of  these  and  the  parts  of  Ptoresource  that  are  unchanged  by  execution  of  transition  (2)  is  exactly 
Presource- 

Transition  (3)  of  the  Resource  program  may  be  enabled.  If  it  is  executed,  it  reads  a  message 
from  R.releaseln  and  places  an  entry  in  R. releases.  This  does  not  change  Rm(c)  for  any  c.  If 
c  =t=  R. current,  it  subtracts  1  from  the  number  of  unread  messages  from  c  while  adding  1  to 
the  number  of  appearances  of  c  in  the  set;  if  c  =  R. current,  it  is  not  possible  that  there  was 
a  message  from  c  on  releaseln,  because  c  is  in  the  busy  state.  This  follows  from  the  message 
histories  for  a  Client  that  is  in  the  busy  state  (Theorem  5.14),  the  message  histories  for  the 
Resource  (Theorem  5.3)  and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system 
state  after  transition  (3)  is  still  Ptoresource- 

Transition  (1)  of  the  Client  program  is  not  enabled  for  any  Client,  because  ( Vc  |  c  e  CS  o 
Cin(c)  =  0)  holds. 

Transitions  (2)  and  (6)  of  the  Client  program  are  not  enabled  for  any  Client  c,  because 
NOTBUSY  holds. 

Transition  (3)  of  the  Client  program  is  enabled  for  Client  c  only  if  c.idle  holds.  It  sends  a 
message  to  R.requestln,  decrementing  C0ut(c)  by  1.  Because  c.idle  holds,  and  the  Resource  is 
idle,  we  know  that  R!fI(c)  +  Cout(c )  =  0.  This  follows  from  the  message  histories  for  a  Client  that 
is  in  the  idle  state  state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem  5.3) 
and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system  state  after  transition  (3) 
is  still  Ptoresource,  but  with  Rin(c)  +  Couf  (c)  =  -1. 

Transition  (4)  of  the  Client  program  does  not  send  a  message  or  cause  a  Client  to  enter  the 
busy  State,  SO  it  does  not  falsify  Presource- 

Transition  (5)  of  the  Client  program  is  enabled  for  Client  c  only  if  c. waiting  holds.  It  sends  a 
message  to  R.releaseln,  incrementing  Cout(c)  by  1.  Because  c.waiting  holds,  and  the  Resource 
is  idle,  we  know  that  Rin(c)  +  C0ut(c)  =  -1.  This  follows  from  the  message  histories  for  a  Client 
that  is  in  the  idle  state  (Theorem  5.14),  the  message  histories  for  the  Resource  (Theorem  5.3) 
and  the  messaging  connections  (Theorem  5.21).  Therefore,  the  system  state  after  transition  (3) 
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is  Still  Ptoresource,  but  With  Rin(c)  +  C„u{(c)  =  0. 

One  or  more  messages  to  the  Resource  may  be  delivered.  If  one  is,  Ptoresource  is  maintained, 
since  the  message  delivery  increments  or  decrements  Cout  (c)  by  1  and  correspondingly  decre¬ 
ments  or  increments  Rin(c)  by  1. 

The  transitions  of  the  Generator  do  not  affect  the  next  property,  since  they  do  not  cause 
any  messages  to  be  sent  or  received  and  all  Clients  created  by  the  Generator  are  initially  idle. 
Therefore,  all  transitions  in  the  system  maintain  the  next  property.  □ 

Theorem  5.26  (Reachable  System  States) 

The  only  reachable  states  for  the  SingleResourceMutualExclusion  system  are  those  where  one  of 
Presource,  Ptoclient,  Pclient  Or  Ptoresource  holds. 


invariant.  (Presource  V  Ptoclient  V  Pclient  V  Ptoresource ) 


Proof 

Initially,  the  system  is  in  a  state  where  Presource  holds,  because  all  mailboxes  are  empty,  no  Client 
processes  exist,  and  the  Resource  process  is  in  the  idle  state.  All  possible  sequences  of  state 
transitions  from  states  where  Presource  hold  establish  only  states  where  one  of  Presource,  Ptoclient, 
Pclient  or  Ptoresource  holds,  as  demonstrated  in  Lemmas  5.22  through  5.25.  Therefore,  the  only 
reachable  states  for  the  system  are  those  where  one  of  Presource,  Ptoclient,  Pclient  or  Ptoresource  hold. 

□ 

Theorem  5.27  (Global  Safety) 

There  is  always  exactly  one  live  token  in  the  SingleResourceMutualExclusion  system. 

invariant.  (LTresource  +  ETclients  +  LTtransit  =  1) 


Proof 

We  show  that  in  every  possible  system  state,  the  number  of  live  tokens  in  the  system  is  exactly 

1. 

In  states  where  Presource  holds,  LTresource  =  1  because  the  Resource  is  in  the  idle  state, 
LTcUents  =  0  because  NOTBUSY  holds,  and  LTtransit  =  0  because  Rout  =  0,  (Vc|ceCS[>-l< 
Rin(c)  +  Cout(c)  <  0),  and  ( Vc  |  c  e  CS\>Cm(c)  =  0)  hold.  Therefore,  the  number  of  live  tokens 
in  the  system  is  exactly  1  in  states  where  Presource  holds. 

In  states  where  Ptoclient  holds,  LTresource  =  0  because  the  Resource  is  in  the  busy  state, 
LTcUents  =  0  because  NOTBUSY  holds,  and  LTtransit  =  1  because  Rout  +  (Zc  \  c  <=  CSoCm(c))  = 
1  and  (Vc|cgC5>-1<  Rm(c)  +  Couf(c)  <  0)  hold.  Therefore,  the  number  of  live  tokens  in 
the  system  is  exactly  1  in  states  where  Ptoclient  holds. 


Ill 


In  states  where  P client  holds,  LTres0urce  =  0  because  the  Resource  is  in  the  busy  state, 
LTdients  =  1  because  BUSY (R. current)  holds,  and  LTtransit  =  0  because  (Vc  |  c  £  CS  t>  -1  < 
Rin(c)  +  Cout(c)  <  0),  Rout  =  0  and  {Vc  |  c  e  CS  t>  C!fJ(c)  =  0)  hold.  Therefore,  the  number  of 
live  tokens  in  the  system  is  exactly  1  in  states  where  Pcuent  holds. 

In  states  where  Ptoresource  holds,  LTreSource  =  0  because  the  Resource  is  in  the  busy  state, 
LTdients  =  0  because  NOTB  USY  holds,  and  LTtransit  =  lbecause  {Vc  |  c  <E  CS  a  c  =t=  R. currents 
-1  <  Rin(c)  +  Cout(c)  <  0),  1  <  Rin(R. current)  +  Cout(R-current)  <  2,  Rout  =  0  and  {Vc  |  c  e 
CS  >  Cm(c)  =  0)  hold.  Therefore,  the  number  of  live  tokens  in  the  system  is  exactly  1  in  stats 
where  P client  holds. 

Since  we  know  from  Theorem  5.26  that  one  of  Presource,  Ptocllent,  Pclient  and  Ptoresource  holds 
in  every  possible  system  state,  there  is  always  exactly  one  live  token  in  the  SingleResourceMu- 
tualExclusion  system.  □ 

We  have  now  shown  that  the  SingleResourceMutualExclusion  system  fulfills  our  safety  con¬ 
dition — at  most  one  Client  is  using  the  Resource  at  any  point  during  the  system’s  execution. 
We  now  show  that  it  fulfills  our  progress  condition,  by  ensuring  that  all  Clients  that  are  in  the 
waiting  state  eventually  enter  the  busy  state  or  leave  the  system. 

Lemma  5.28  (Resource  Process  Serving  Progress) 

The  Resource  in  the  SingleResourceMutualExclusion  system  always  eventually  becomes  idle. 

R.busy  R.idle 


Proof 

Assume  R  is  busy,  and  remains  so  forever.  R. current  is  a  Client  process,  because  only  Client 
processes  send  messages  to  R.requestln  (by  inspection).  We  know  from  Theorem  5.3  that  the 
difference  between  the  number  of  releases  received  by  R  from  R. current  and  the  number  of 
tokens  sent  by  R  to  R. current  is  exactly  the  number  of  instances  of  R. current  in  R. releases 
minus  1.  We  know  that  the  number  of  instances  of  R. current  in  R. releases  is  zero,  because  if 
it  were  not,  R  would  become  idle  as  shown  in  Theorem  5.6,  contradicting  our  assumption.  So 
the  number  of  tokens  sent  by  R  to  R. current  is  exactly  one  greater  than  the  number  of  releases 
received  by  R  from  R. current,  and  no  future  release  is  ever  received  by  R  from  R. current  (since 
this  would  lead  to  R  becoming  idle). 

Because  of  the  messaging  connections  of  Theorem  5.21,  this  means  that  the  number  of 
tokens  received  by  R. current  must  become  exactly  one  greater  than  the  number  of  releases 
sent  by  R. current  and  remain  that  way  forever.  However,  R. current  is  a  Client  process,  and 
Corollary  5.16  tells  us  that  if  a  Client  process  has  received  more  tokens  than  it  has  sent  releases, 
it  will  eventually  reach  a  state  where  it  has  received  the  same  number  of  tokens  as  it  has  sent 
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releases.  This  is  a  contradiction,  because  it  means  that,  eventually,  R  will  receive  another 
release  from  R. current.  R  therefore  cannot  remain  busy  forever.  □ 

Theorem  5.29  (Global  Progress) 

All  Client  processes  that  are  waiting  to  access  the  Resource  in  the  SingleResourceMutualExclusion 
system  eventually  either  get  access  to  the  Resource  or  leave  the  system. 

(Vp  |  p  G  T  a  (3r  \>  p  =  Client(r))  >  p .waiting  ^  p.busy  v  p.gone) 


Proof 

Combining  Theorems  5.5,  5.28  and  5.26  with  the  knowledge  that  request  messages  cannot  be 
overtaken  once  they  are  delivered  to  the  Resource’s  “requestin’’  inbox  tells  us  that  every  Client 
that  sends  a  request  (that  is,  every  client  that  enters  the  waiting  state)  will  eventually  be  sent 
a  token.  When  this  happens,  the  Client  will  have  the  opportunity  to  enter  the  busy  state  when 
that  token  reaches  its  inbox,  fulfilling  the  leads-to  condition.  Additionally,  transition  (5)  of  the 
Client  is  an  unfair  transition  that  allows  the  Client  to  go  from  the  waiting  state  to  the  gone 
state.  This  also  fulfills  the  leads-to  condition.  Since  the  busy  state  will  eventually  result  in  all 
executions  except  those  where  the  gone  state  results,  the  leads-to  condition  is  always  fulfilled. 

□ 
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Chapter  6 

Nondeterministic  Example  2:  Dynamic 
Drinking  Philosophers 

Our  third  and  final  example  Dynamic  UNITY  system  is  a  solution  to  a  particular  resource  al¬ 
location  problem  called  the  dynamic  drinking  philosophers  problem.  This  example  demon¬ 
strates  many  of  Dynamic  UNITY’S  features,  as  both  clients  and  resources  can  enter  and  leave 
the  system,  and  the  set  of  resources  required  by  a  particular  client  can  change.  It  is  also  far 
more  complex  than  the  previous  example,  which  demonstrates  the  applicability  of  the  Dynamic 
UNITY  formalism  to  more  complex  problems. 

6.1  Problem  Statement 

Many  systems  exist  where  a  single  client  requires  simultaneous  exclusive  access  to  multiple 
resources.  For  instance,  a  process  running  on  a  machine  with  a  shared  filesystem  may  need 
write  access  to  several  files,  and  may  not  be  able  to  complete  its  computation  until  it  gets  this 
access.  If  this  system  is  dynamic,  both  the  set  of  running  client  processes  and  the  set  of  hies 
in  the  hie  system  may  change. 

The  drinking  philosophers  problem  [7],  or  drinkers  problem,  is  a  generalization  of  the  dining 
philosophers  problem  that  models  multiple  resource  mutual  exclusion  in  static  environments. 
For  this  problem,  a  system  consists  of  a  set  of  processes  (the  philosophers),  each  of  which  can 
be  in  one  of  three  states:  tranquil,  thirsty  and  drinking.  The  only  allowed  state  transitions  are 
tranquil  —  thirsty  —  drinking  —  tranquil,  and  it  is  guaranteed  that  no  philosopher  remains  in 
the  drinking  state  forever.  A  nonempty  set  of  resources  (the  beverages)  is  associated  with  each 
philosopher  that  is  in  the  thirsty  or  drinking  state,  and  this  set  remains  unchanged  until  that 
philosopher  becomes  tranquil  again;  when  a  tranquil  philosopher  becomes  thirsty,  its  set  of 
beverages  may  change.  The  problem  is  to  ensure  that  no  two  philosophers  who  have  a  beverage 
in  common  drink  at  the  same  time,  and  that  every  thirsty  philosopher  drinks  eventually.  This 
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is  the  same  as  ensuring  that  every  process  in  a  system  eventually  receives  simultaneous  access 
to  all  the  resources  it  requires  to  complete  its  computation. 

The  dynamic  drinking  philosophers  problem  extends  the  drinkers  problem  to  model  dy¬ 
namic  environments  in  the  following  way:  instead  of  a  static  set  of  philosophers  and  a  static 
set  of  beverages,  the  system  contains  dynamic  sets  of  both.  Beverages  may  enter  and  leave 
the  system,  and  so  may  philosophers.  We  allow  a  beverage  to  leave  the  system  at  any  time 
when  it  is  not  being  consumed,  and  we  allow  a  philosopher  to  leave  the  system  at  any  time. 
The  progress  condition  in  this  system  is  different  from  that  of  the  traditional  drinkers  prob¬ 
lem:  since  beverages  and  philosophers  can  leave  the  system  at  any  time,  we  guarantee  that  a 
thirsty  philosopher  will  eventually  drink  or  leave  the  system  rather  than  guaranteeing  that  it 
will  eventually  drink.  In  addition,  we  don’t  guarantee  that  a  thirsty  philosopher  receives  all  the 
beverages  in  its  beverage  set.  Instead,  we  guarantee  that  the  thirsty  philosopher  receives  all 
the  beverages  in  its  beverage  set  that  have  not  left  the  system.  This  is  the  same  as  ensuring 
that  every  process  in  a  system  eventually  receives  simultaneous  access  to  all  of  its  requested 
resources  that  still  exist  in  the  system.  An  alternative  specification  is  one  in  which  a  process’s 
request  is  cancelled  when  one  or  more  of  the  resources  it  requests  is  no  longer  in  the  sys¬ 
tem;  our  choice  of  specification  is  predicated  on  the  assumption  that  obtaining  some  required 
resources  is  often  better  than  obtaining  none. 

We  choose  to  solve  this  problem  with  an  algorithm  that  uses  tokens  (which  are  also  used  in 
most  solutions  to  the  traditional  drinkers  problem)  and  monotonically  increasing  local  clocks 
to  handle  mutual  exclusion  and  request  prioritization.  These  local  clocks  are  not  systemwide 
logical  clocks  in  the  sense  of  Lamport  [33]  or  Jefferson  [28]— systemwide  logical  clocks  guar¬ 
antee  causality  of  message  ordering,  while  our  clocks  only  guarantee  that  requests  occur  with 
monotonically  increasing  timestamps. 

Every  beverage  has  a  unique  and  indivisible  token  associated  with  it,  and  the  holder  of  the 
token  has  exclusive  access  to  that  beverage.  Every  philosopher  in  the  system  is  implemented 
as  a  separate  Dynamic  UNITY  process  with  its  own  independent  local  clock,  and  local  clock 
times  are  used  to  prioritize  requests  for  beverages  and  prevent  deadlock.  When  a  philosopher 
becomes  thirsty,  it  sends  requests  to  all  the  beverages  in  its  beverage  set.  When  it  receives  the 
tokens  corresponding  to  all  its  beverages,  it  has  exclusive  access  to  the  beverage  set  and  can 
drink. 

The  dynamic  aspects  of  the  system  render  the  traditional  drinking  philosophers  algorithm 
insufficient  to  ensure  system  progress,  even  with  the  addition  of  logical  clocks.  Clearly,  if  a 
philosopher  were  to  simply  disappear  after  requesting  a  set  of  beverages  the  system  would 
deadlock,  because  the  beverage  tokens  would  eventually  be  sent  to  the  vanished  philosopher 
and  would  never  be  returned.  Similarly,  if  a  beverage  were  to  leave  the  system  while  still 
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type 

Request:  record  {philosopher:  process,  timestamp:  integer} 

Release:  process 

Token:  process 

Demand:  process 

BLeave:  process 

PLeave:  process 

BeverageSetRequest:  process 

BeverageSet:  set {process} 


Specification  6.1:  Message  types  for  the  dynamic  drinking  philosophers  system 


being  in  the  beverage  sets  of  one  or  more  philosophers  the  system  would  deadlock,  because 
the  philosophers  would  be  waiting  for  tokens  that  would  never  arrive.  To  account  for  these 
situations  in  the  dynamic  system,  we  introduce  an  additional  Dynamic  UNITY  process  called 
the  coordinator  that  coordinates  the  entry  and  exit  of  processes  to  and  from  the  system.  Much 
of  the  coordinator’s  functionality  is  analogous  to  that  of  a  distributed  directory  service,  and 
would  be  implemented  as  such  in  an  actual  distributed  system;  we  choose  to  implement  it  as 
a  single  Dynamic  UNITY  process  for  simplicity. 

Every  message  passed  in  the  system  contains  either  one  token  or  no  tokens;  there  are  no 
multiple-token  messages.  In  addition,  every  request  message  contains  a  timestamp  that  is 
used  to  establish  the  priority  of  requests  from  different  philosophers.  We  assume  that  time- 
stamps  from  different  philosophers  are  unique  (that  is,  that  no  two  messages  from  different 
philosophers  can  have  the  same  timestamp).  This  is  a  reasonable  assumption,  since  it  is  always 
possible  to  break  timestamp  ties  using  a  systemwide  unique  identifier  as  a  tiebreaker. 

We  specify  the  components  of  our  system  individually  and  give  a  high  level  description 
of  their  behavior.  We  then  prove  a  particular  progress  condition,  namely  that  there  exists  a 
metric  that  ensures  that  a  thirsty  philosopher  will  eventually  reach  the  drinking  state.  We  do 
not  carry  out  a  full  proof  of  the  dynamic  drinking  philosophers  system,  as  previous  chapters 
have  already  demonstrated  our  proof  method  in  detail. 

We  first  specify  some  message  types  that  will  be  used  for  communication  among  the  pro¬ 
cesses  in  our  system.  This  allows  us  to  avoid  replicating  the  same  type-section  in  all  three 
programs.  For  the  purposes  of  this  discussion,  we  assume  all  messages  in  the  system  are  of 
one  of  these  message  types.  This  makes  our  programs  less  complicated,  eliminating  the  need 
to  filter  out  messages  of  other  unexpected  types  that  may  arrive  on  the  inboxes. 


6.2  Message  Types 
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The  message  types  of  Specification  6.1  allow  processes  in  a  dynamic  drinking  philosophers 
system  to  distinguish  between  messages  that  carry  otherwise  identically-typed  information  (6 
of  the  8  message  types  consist  solely  of  a  process  reference).  Request  and  Release  are  message 
types  sent  from  a  philosopher  to  a  beverage,  to  request  a  token  and  release  a  token;  Token 
and  Demand  are  message  types  sent  by  a  beverage  to  a  philosopher,  containing  a  token  and  a 
demand  for  the  return  of  its  token;  BLeave  is  a  message  type  sent  by  a  beverage  to  the  coordina¬ 
tor,  and  then  by  the  coordinator  to  all  philosophers  in  the  system,  announcing  the  beverage’s 
departure  from  the  system;  PLeave  is  a  message  type  sent  by  a  philosopher  to  the  coordinator 
and  the  beverages,  informing  them  of  its  departure  from  the  system;  BeverageSetRequest  is  a 
message  type  sent  by  a  philosopher  to  the  coordinator  requesting  a  new  beverage  set;  and  Bev- 
erageSet  is  a  message  type  sent  by  the  coordinator  to  a  philosopher  containing  a  new  beverage 
set. 


6.3  The  Beverage  Program 

Each  beverage  (Specification  6.2)  starts  in  a  state  where  it  is  holding  its  own  token.  It  continually 
receives  requests  from  philosophers,  and  services  them  in  the  following  way.  The  requests  are 
sorted  according  to  their  timestamps,  and  the  earliest  timestamp  is  always  serviced  if  possible. 
If  anew  request  comes  in  with  an  earlier  timestamp  than  the  one  that  is  currently  being  serviced, 
the  beverage  demands  the  token  back  from  the  philosopher  to  which  it  had  last  sent  the  token. 
In  this  way,  a  priority  queue  of  philosophers  is  established.  Since  the  philosophers  always 
request  their  entire  set  of  beverages  with  the  same  timestamp,  this  gives  a  global  priority 
to  each  philosopher  and  prevents  deadlocks  that  could  be  caused  by  priority  cycles  among 
philosophers  competing  for  multiple  beverages.  A  beverage  can  only  leave  the  system  when  it 
holds  its  own  token  (that  is,  when  it  is  guaranteed  to  not  be  in  use  by  a  philosopher),  and  when 
it  does  so,  it  sends  a  notification  to  the  coordinator.  This  allows  the  coordinator  to  notify  the 
philosophers,  so  they  can  remove  the  beverage  from  their  beverage  sets. 

6.4  The  Philosopher  Program 

Each  philosopher  (Specifications  6. 3-6. 5)  starts  in  the  tranquil  state.  On  a  transition  to  the 
thirsty  state,  it  sends  requests  to  all  the  beverages  in  its  set  and  waits  for  the  tokens  corre¬ 
sponding  to  them.  These  requests  are  all  stamped  with  the  philosopher’s  current  local  time, 
called  the  request  time,  and  this  time  is  also  recorded  locally  in  the  philosopher’s  state.  It  is  pos- 
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program  Beverage  (coordinator:  process) 
declare 

philosopherln:  inbox 
requests:  set  {Request} 
releases:  set  {Release} 
current:  Request 
demandSent:  boolean 

always 

idle  =  current  =  _l; 
busy  =  -i  idle 

initially 

idle  A  requests  =  0  A  releases  =  0  A  demandSent  =  false 
fair-transition 

(1)  philosopherln.probe  A  philosopherln.current.msg.type  =  Request  — * 

requests'  =  requests  u  {philosopherIn.current.msg}  A 
philosopherln.advance 

(2)  0  philosopherln.probe  A  philosopherln.current.msg.type  =  Release  — * 

releases'  =  releases  u  {philosopherln.current.msg}  A 
philosopherln.advance 

(3)  0  idle  A  requests  ^0  — » 

(3  r  |  r  G  requests  A  r. timestamp  =  (min  s  |  s  G  requests  >  s.timestamp)  \> 
current'  =  r  a  requests'  =  requests  \  {r}  a 
send(r.philosopher,  “beverageln”,  Token(this)))  A 
demandSent'  =  false 

(4)  0  busy  A  (3  r  |  r  G  requests  >  r.timestamp  <  current. timestamp)  A 

-■demandSent  — * 

send(current.philosopher,  “beverageln”,  Demand(this))  A 
demandSent'  =  true 

(5)  Q  busy  A  (3  r  |  r  G  releases  >  r.philosopher  =  current.philosopher)  — * 

releases'  = 

releases  \  {r  |  r  G  releases  >  r.philosopher  =  current.philosopher}  A 
current  =  _L 

unfair-transition 

(6)  idle  — ►  send(coordinator,  “in”,  BLeave(this))  a  stop 


end 


Specification  6.2:  The  Beverage  program,  part  of  the  dynamic  drinking  philosophers  system 
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program  Philosopher  (coordinator:  process,  initialBeverages:  set  {process}, 
initialTime:  integer) 


declare 

beverageln,  coordinatorln:  inbox 
beverages:  set  {process} 
requests:  set  {process} 
tokens:  set  {Token} 
demands:  set  {Demand} 
requestTime:  integer 
clock:  integer 

tranquil,  thirsty,  drinking:  boolean 
always 

gone  =  -■tranquil  A -'thirsty  A -'drinking 


initially 

beverages  =  initialBeverages  A  tokens  =  0  A  demands  =  0  A 

clock  =  initialTime  A  tranquil  =  true  a  thirsty  =  false  A  drinking  =  false 

fair-transition 

(Specification  6.4) 

unfair-transition 

(Specification  6.5) 


end 


Specification  6.3:  The  Philosopher  program,  part  of  the  dynamic  drinking  philosophers  system 
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(1)  beverageln.probe  A  beverageln.current.msg.type  =  Token  — * 

tokens'  =  tokens  u  {beverageln.current.msg}  a  beverageln.advance 

(2)  0  beverageln.probe  a  beverageln.current.msg.type  =  Demand  A 

(3  t  |  t  €  tokens  >  t.beverage  =  beverageln.current.msg.beverage)  — * 

demands'  =  demands  u  {beverageln.current.msg}  a  beverageln.advance 

(3)  0  beverageln.probe  A  beverageln.current.msg.type  =  Demand  A 

-i  <3  t  |  t  e  tokens  >  t.beverage  =  beveragelmcurrent.msg.beverage)  — * 
beverageln.advance 

(4)  0  coordinatorln.probe  A  coordinatorln.current.type  =  BLeave  — * 

beverages'  =  beverages  \  {coordinatorln.current.msg.beverage}  A 
coordinatorln.advance 

(5)  Q  tranquil  a  coordinatorln.probe  A  coordinatorln.current.type  =  BeverageSet  — < 

beverages'  =  coordinatorln.current.msg.beverages  A  coordinatorln.advance 

(6)  0  tranquil  A  coordinatorln.probe  A  coordinatorln.current.type  =  BeverageSet  — * 

coordinatorln.advance 

(7)  D  thirsty  A  (3  r  |  r  e  beverages  >  r  <£  requests)  — * 

requests'  =  beverages  A 

send((,  r  |  r  e  beverages  A  r  <£  requests  > 

r,  “philosopherln”,  Request(this,  requestTime))) 

(8)  D  thirsty  A  (V  r  |  r  e  beverages  >  <3  t  |  t  e  tokens  >  t.beverage  =  r))  — * 

thirsty'  =  false  A  drinking'  =  true 

(9)  0  drinking  — * 

drinking'  =  false  A  tranquil'  =  true  A 

send((,  t  |  t  €  tokens  >  t.beverage,  “philosopherln”,  Release(this)))  A 
requests'  =  0  a  demands'  =  0  a  tokens'  =  0 

(10)  D  “'drinking  A  (3  d,  t  |  d  e  demands  Ate  tokens  o  t.beverage  =  d.beverage)  — * 

send((,  d  |  d  <s  demands  A  (3  t  |  t  e  tokens  >  t.beverage  =  d.beverage)  > 

d.beverage,  “philosopherln”,  Release(this)))  A 

demands'  =  demands  \ 

{d  |  d  G  demands  A  (3  t  |  t  e  tokens  o  t.beverage  =  d.beverage)}  A 
tokens'  =  tokens  \ 

{t  |  t  e  tokens  a  (3  d  |  d  e  demands  o  t.beverage  =  d.beverage)}  A 
requests'  =  requests  \ 

{r  |  r  <G  requests  A  (3  d  |  d  e  demands  o  r. beverage  =  d.beverage)} 

(11) 0  clock'  =  clock  +  1 

Specification  6.4:  Fair  transition  section  of  the  Philosopher  program 

(12)  tranquil  — » 

requests'  =  beverages  A  tranquil'  =  false  a  thirsty'  =  true  A 
requestTime'  =  clock  a  clock'  =  clock  +  1  A 

send((,  r  |  r  e  beverages  >  r,  “philosopherln”,  Request(this,  clock))) 

(13)  0  tranquil  a  beverages  4  0  — * 

beverages'  =  0  A  send(coordinator,  “in”,  BeverageSetRequest(this)) 

(14)  0  tranquil  — ►  tranquil'  =  false  A  send(coordinator,  “in”,  PLeave(this))  A  stop 

(15)  0  thirsty  v  drinking  — * 

thirsty'  =  false  A  drinking'  =  false  A 

requests'  =  0  A  tokens'  =  0  A  demands'  =  0  A 

send((,  r  |  r  e  requests  >  r,  “philosopherln”,  Release(this)))  A 

send(coordinator,  “in”,  PLeave(this))  A  stop 

Specification  6.5:  Unfair  transition  section  of  the  Philosopher  program 
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sible  for  the  philosopher  to  receive  a  token  and  then  subsequently  have  that  token  demanded 
back  by  the  beverage  associated  with  it;  if  the  philosopher  is  not  already  drinking  when  this 
happens,  it  returns  the  token  and  makes  another  request  with  the  same  request  time  as  it  used 
originally.  In  this  way,  philosophers  maintain  their  global  priority  relative  to  the  other  philoso¬ 
phers.  When  the  philosopher  holds  the  tokens  of  all  its  beverages,  it  enters  the  drinking  state, 
and  when  it  leaves  the  drinking  state  it  sends  the  tokens  back  and  enters  the  tranquil  state.  A 
philosopher  can  leave  the  system  regardless  of  what  state  it  is  in,  but  it  must  send  releases  to 
any  beverages  in  its  beverage  set  for  which  it  has  outstanding  requests  (regardless  of  whether 
or  not  it  holds  the  tokens  for  them).  This  prevents  deadlock  by  ensuring  that  all  the  beverages 
will  get  their  tokens  back,  or  will  not  send  them  out  in  the  first  place  if  a  release  arrives  before 
the  corresponding  request  is  serviced. 


6.5  The  Coordinator  Program 


program  Coordinator 

declare 
in:  inbox 

beverages:  set  {process} 
philosophers:  set  {process} 
clock:  integer 

initially 

beverages  =  0  A  philosophers  =  0  A  clock  =  0 

fair-transition 

(1)  in.probe  a  in.current.msg.type  =  BLeave  — * 

beverages'  =  beverages  \  {in.current.msg.beverage}  a 

send((,  pipe  philosophers  >  p,  “coordinatorln”,  in.current.msg)) 

(2)  0  in.probe  a  in.current.msg.type  =  PLeave  — * 

philosophers'  =  philosophers  \  {in.current.msg.philosopher} 

(3)  D  in.probe  a  in.current.msg.type  =  BeverageSetRequest  — * 

s:  s  e  beverages  A 

send(in.current.msg.philosopher,  “coordinatorln”,  BeverageSet(s)) 

(4)  0  clock'  =  clock  +  1 

unfair-transition 

(5)  beverages'  =  beverages  u  {new  Beverage(this)} 

(6)  D  s:  s  e  beverages  A 

philosophers'  =  philosophers  u  {new  Philosopher(this,  s,  clock)}  A 
clock'  =  clock  +  1 


Specification  6.6:  The  Coordinator  program,  part  of  the  dynamic  drinking  philosophers  system 
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The  function  of  the  coordinator  (Specification  6.6)  is  to  model  the  resource  discovery  and 
failure  notification  algorithms  that  would  be  used  in  an  actual  implementation  of  a  dynamic 
drinking  philosophers  system.  It  is  essentially  a  directory  service — it  creates  and  keeps  track 
of  all  the  system’s  beverages  and  philosophers,  and  is  responsible  both  for  assigning  beverage 
sets  to  philosophers  and  for  distributing  notifications  when  a  philosopher  or  beverage  leaves 
the  system.  When  a  beverage  leaves  the  system,  all  the  philosophers  in  the  system  are  notified 
of  its  departure  so  that  the  beverage  can  be  removed  from  their  beverage  sets. 

The  coordinator,  like  the  beverages  and  philosophers,  has  a  local  clock.  This  clock  is  used 
to  initialize  the  local  clocks  of  newly  created  beverages  and  philosophers  and  is  important 
in  preventing  infinite  overtaking  of  thirsty  philosophers  by  new  philosophers  that  enter  the 
system. 


6.6  The  Composed  System 


system  DynamicDrinkingPhilosophers 
initial-program  Coordinator 

program  Beverage  (coordinator:  process,  initialTime:  integer) 

program  Philosopher  (coordinator:  process,  initialBeverages:  set  {process}, 
initialTime:  integer) 


end 


Specification  6.7:  The  DynamicDrinkingPhilosophers  system 


The  composed  system  (Specification  6.7)  contains  a  single  coordinator,  instantiated  as  the 
initial  process.  We  do  not  present  a  full  proof  of  correctness  for  the  system  because  most  of  the 
concepts  that  would  be  illustrated  by  such  a  proof  have  already  been  demonstrated  in  previous 
chapters.  Instead,  we  give  a  partial  proof  that  establishes  the  main  progress  property  for  the 
system. 

6.6.1  Partial  Proof  of  Progress 

We  present  a  partial  proof  of  system  progress  by  formulating  and  proving  the  validity  of  a 
progress  metric  that  guarantees  every  thirsty  philosopher  will  eventually  drink  or  leave  the 
system.  This  is  only  a  partial  proof  because  we  use  an  assumption  about  the  token  passing 
behavior  of  the  system  in  order  to  prove  the  correctness  of  our  metric.  In  order  to  formulate 
our  metric,  we  first  define  and  prove  properties  of  the  quantities  that  will  be  used  in  the  metric. 
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For  the  remainder  of  this  section,  we  denote  the  set  of  philosophers  in  a  drinking  philosophers 
system  by  T,  and  the  coordinator  process  in  the  system  by  c. 

We  first  define  a  quantity  that  reflects  the  difference  between  a  philosopher’s  request  time 
and  the  coordinator’s  local  time,  and  prove  that  it  is  monotonically  nonincreasing. 

Definition  6.1  (Coordinator  Difference)  The  coordinator  difference  fora  thirsty  philoso¬ 
pher^,  denoted CD(p),  is  the  difference  between  p ’s  request  time  and  the  coordinator’s  local  time, 
or  0,  whichever  is  greater. 


CD(p )  =  max(p .requestTime  -  c. clock,  0) 

Lemma  6.2  (Coordinator  Difference  Monotonicity) 

CD(p)  is  monotonically  nonincreasing. 

(Vk  >  CDip)  =  k  next  CD(p)  <  k ) 


Proof 

We  prove  this  next  property  by  examining  the  effect  of  every  transition  of  the  system’s  programs 
on  CDip),  given  that  p  is  in  the  thirsty  state. 

Only  two  transitions  of  the  Coordinator  program,  (4)  and  (6),  modify  c. clock.  Both  of  these 
transitions  increment  the  value  of  c. clock  by  1.  Therefore,  both  of  these  transitions  satisfy  the 
next  property  by  reducing  CDip )  (if  it  is  greater  than  0)  or  leaving  it  unchanged  (if  it  is  less 
than  or  equal  to  0).  The  transitions  that  do  not  modify  c. clock  satisfy  the  next  property  by 
leaving  CDip)  unchanged. 

No  transition  of  the  Philosopher  program  modifies  p .requestTime  when  p  is  in  the  thirsty 
state.  The  one  transition  that  modifies  p .requestTime,  (12),  is  enabled  only  in  the  tranquil  state. 

We  have  shown  that  every  transition  of  the  Coordinator  and  Philosopher  programs  either 
leaves  CDip)  unchanged  or  decreases  it.  No  transition  of  any  other  program  in  the  system 
can  modify  CDip),  because  it  is  calculated  solely  from  state  variables  of  the  Philosopher  and 
Coordinator  programs.  Therefore,  the  next  property  holds.  □ 

Next,  we  define  a  quantity  PDip)  that  reflects  the  maximum  number  of  times  a  philoso¬ 
pher  p  can  be  overtaken  by  other  philosophers  currently  in  the  system.  We  then  show  that 
the  lexicographic  pair  iCDip),PDip)  is  monotonically  nondecreasing,  and  that  its  value  must 
eventually  decrease  if  it  is  greater  than  (0,  0). 

Definition  6.3  (Philosopher  Difference)  The  maximum  number  of  times  a  thirsty  philoso¬ 
pher  p  can  be  overtaken  by  another  philosopher  q  in  the  system  is  the  difference  between  p’s 
request  time  and  q’s  local  time,  or  0,  whichever  is  greater.  The  philosopher  difference  for  a 
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thirsty  philosopher  p,  denoted  PD (p),  is  the  maximum  number  of  times  a  philosopher  p  can  be 
overtaken  by  all  other  philosophers  in  the  system. 

PD(p)  =  (Zq  |  q  G  T  >  maxip .requestTime  -  q.clock,0)) 

Lemma  6.4  ((CD,  PD)  Monotonicity) 

The  lexicographic  pair  (CD(p),  PD(p))  is  monotonically  nonincreasing. 

( Vk,  Z  >  (CD(p),PD(p))  =  (k,l)  next  (CD(p),  PD(p))  <  ( k,l) ) 


Proof 

We  prove  this  next  property  by  examining  the  effect  of  every  transition  of  the  system’s  programs 
on  (CD(p),  PD(p)),  given  that  p  is  in  the  thirsty  state.  We  have  already  shown  that  CD(p)  is 
monotonically  nonincreasing.  Therefore,  all  we  must  show  is  that  if  PD(p)  increases,  there  is 
a  corresponding  decrease  in  CD(p). 

We  begin  with  the  Philosopher  program.  Since  no  transition  of  p  that  is  enabled  when  p  is 
in  the  thirsty  state  changes  the  value  of  p .requestTime,  execution  of  any  transition  of  p  leaves 
PD(p)  unchanged.  For  every  philosopher  q  in  the  system,  where  q  f  p,  the  transitions  have 
the  following  effects: 

•  Transitions  (1)  through  (10),  and  (13),  do  not  change  q.clock  and  do  not  remove  q  from 
the  system.  Therefore,  they  do  not  affect  the  value  of  PD(p). 

■  Transitions  (11)  and  (12)  each  increase  q.clock  by  1,  and  do  not  remove  q  from  the  system. 
Therefore,  they  either  decrease  PD(p )  by  1  (if  p .requestTime  >  q.clock)  or  leave  its  value 
unchanged  (if  p. requestTime  <  q.clock). 

■  Transitions  (14)  and  (15)  remove  q  from  the  system.  Therefore,  they  either  decrease  PD(p) 
(if  p. requestTime  >  q.clock)  or  leave  its  value  unchanged  (if  p .requestTime  <  q.clock). 

We  continue  with  the  Coordinator  program.  The  transitions  of  the  Coordinator  program 
have  the  following  effects: 

•  Transitions  (1)  through  (5)  do  not  add  new  philosophers  to  the  system.  Therefore,  they 
do  not  affect  the  value  of  PD(p). 

■  Transition  (6)  increases  c. clock  by  1  and  adds  a  new  philosopher  to  the  system.  The  new 
philosopher’s  clock  value  is  initialized  to  the  value  of  c. clock.  Therefore,  if  p .requestTime 
>  c. clock,  it  increases  PD(p)  by  the  difference  between  them  and  decreases  CD(p)  by  1, 
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the  net  effect  of  which  is  to  decrease  (CD(p),PD(p)).  If  p  .requestTime  <  c. clock,  it  leaves 
the  values  of  both  CD(p)  and  PD(p)  unchanged. 

We  have  shown  that  every  transition  of  the  Philosopher  and  Coordinator  programs  either 
leaves  ( CD(p),PD(p ))  unchanged  or  decreases  it.  No  transition  of  any  other  program  in  the 
system  can  modify  ( CD(p),PD(p )),  because  it  is  calculated  solely  from  state  variables  of  the 
Philosopher  and  Coordinator  programs.  Therefore,  the  next  property  holds.  □ 

Lemma  6.5  ((CD,  PD)  Transience) 

If  (CD(p),  PD(p))  >  (0,0),  it  will  eventually  decrease. 

<  Vk,  l  |  k  >  0  a  /  >  0  a  (k,  l)  ±  (0, 0)  >  transient.) ( CD(p ),  PD(p))  =  (k,  /))) 


Proof 

We  prove  this  transient  property  by  examining  the  transitions  of  the  Coordinator  and  Philoso¬ 
pher  programs.  Transition  (4)  of  the  Coordinator  program  is  a  fair  transition  that  is  always 
enabled,  and  that  increases  the  value  of  c. clock  by  1.  Transition  (11)  of  the  Philosopher  pro¬ 
gram  is  a  fair  transition  that  is  always  enabled,  and  that  increases  the  value  of  q. clock  by  1  for 
a  philosopher  q.  Therefore,  if  ( CD(p),PD(p ))  >  (0,0),  execution  of  one  of  these  transitions 
will  reduce  its  value.  This  is  sufficient  to  prove  the  transient  property.  □ 

Finally,  we  define  a  quantity  HP(p)  that  reflects  the  number  of  thirsty  philosophers  in  the 
system  with  higher  priority  than  a  particular  philosopher  p.  We  then  show  that  the  lexico¬ 
graphic  triple  (CD(p),PD(p),HP(p))  is  monotonically  nondecreasing. 

Definition  6.6  (Higher  Priority)  A  thirsty  philosopher  q  has  a  higher  priority  than  another 
thirsty  philosopher  p  if  q ’s  request  time  is  earlier  than  p’s  request  time.  We  denote  the  number 
of  philosophers  in  the  system  that  have  higher  priority  than  p  by  HP(p). 

HP(p)  =  {#q  |  q  e  T  a  (q. thirsty  v  q. drinking)  >  q.requestTime  <  p .requestTime) 

Lemma  6.7  ((CD,  PD,  HP)  Monotonicity) 

The  lexicographic  triple  (CD(p), PD(p),  HP(p))  is  monotonically  nonincreasing. 


(\/k,l,m  >  ( CD(p),PD(p),HP(p ))  =  (k,l,m)  next  ( CD(p),PD(p),HP(p ))  <  ( k,l,m )) 
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Proof 

We  prove  this  next  property  by  examining  the  effect  of  every  transition  of  the  system’s  programs 
on  ( CDip) ,  PDip) ,  HPip )),  given  that  p  is  in  the  thirsty  state.  We  have  already  shown  that 
( CD(p),PD(p ))  is  monotonically  nonincreasing.  Therefore,  all  we  must  show  is  that  if  HPip ) 
increases,  there  is  a  corresponding  decrease  in  (CD(p),PD(p)). 

We  begin  with  the  Philosopher  program.  Since  no  transition  of  p  that  is  enabled  when  p  is 
in  the  thirsty  state  changes  the  value  of  p.requestTime,  execution  of  any  transition  of  p  leaves 
HP(p)  unchanged.  For  every  philosopher  q  in  the  system,  where  q  f  p,  the  transitions  have 
the  following  effects: 

•  Transitions  (1)  through  (7),  (10),  (11),  and  (13)  do  not  change  the  state  of  q.  Therefore, 
they  do  not  affect  the  value  of  HP(p). 

■  Transition  (8)  changes  the  state  of  q  from  thirsty  to  drinking.  It  does  not  affect  the  value 
of  HP(p),  because  HP(p)  counts  both  thirsty  and  drinking  philosophers. 

•  Transition  (9)  changes  the  state  of  q  from  drinking  to  tranquil.  It  therefore  either  de¬ 
creases  HP(p)  by  1  (if  q.requestTime  <  p .requestTime)  or  leaves  its  value  unchanged  (if 
q.requestTime  >  p .requestTime). 

■  Transition  (12)  changes  the  state  of  q  from  tranquil  to  drinking,  and  increments  q. clock 
by  1.  Therefore,  if  q. clock  <  p.requestTime,  it  increases  HPip)  by  1  and  decreases 
PD(p)  by  1,  the  net  effect  of  which  is  to  decrease  ( CD(p),PD(p),HP(p )).  If  q. clock  > 
p .requestTime,  it  leaves  the  values  of  both  HPip)  and  PD(p)  unchanged. 

We  have  shown  that  every  transition  of  the  Philosopher  program  either  leaves  (CD(p), 
PD(p),  HPip))  unchanged  or  decreases  it.  No  transition  of  any  other  program  in  the  sys¬ 
tem  can  modify  HPip),  because  it  is  calculated  solely  from  state  variables  of  the  Philosopher 
program,  and  we  have  previously  shown  that  iCDip),  PDip))  is  monotonically  nondecreasing. 
Therefore,  the  next  property  holds.  □ 

Having  defined  these  quantities  and  proven  monotonicity  and  transience  properties  for 
them,  we  can  use  them  to  establish  a  progress  metric  as  follows. 

Theorem  6.8  (Progress  Metric) 

If  p  is  a  thirsty  philosopher  in  a  dynamic  drinking  philosophers  system,  the  triple  (CD(p),  PD(p), 
HP(p))  is  a  lexicographic  progress  metric  for  p. 


Mip)  4  iCDip), PDip), HPip)) 
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Proof 

To  prove  that  M(p)  is  a  progress  metric,  we  need  to  show  that  M(p)  has  a  lower  bound,  that 
M(p)  never  increases,  that  if  p  doesn’t  drink  and  doesn’t  leave  the  system  M(p)  eventually 
decreases,  and  that  when  M(p)  has  reached  its  lower  bound  p  is  guaranteed  to  either  drink  or 
leave  the  system. 

In  this  proof,  we  rely  on  properties  of  the  Beverage  and  Philosopher  programs  that  have  not 
been  explicitly  proven  elsewhere;  in  a  complete  proof  of  the  system,  we  would  need  to  prove 
these  properties  as  well.  In  particular,  we  assume  that  if  a  philosopher  retains  the  highest 
priority  long  enough,  it  eventually  receives  all  its  tokens  (and  therefore  eventually  drinks). 
This  is  a  reasonable  assumption,  because  we  know  that  if  a  philosopher  has  the  highest  priority, 
there  are  no  other  philosophers  in  the  thirsty  or  drinking  states  that  have  earlier  request  times. 
Therefore,  that  philosopher  (which  we  call  q)  is  either  the  current  requestor  or  the  head  of  the 
request  queue  for  every  beverage  in  its  beverage  set.  If  q  is  the  current  requestor  for  a  beverage 
b,  it  either  holds  b’s  token  or  will  hold  it  when  it  arrives.  If  q  is  the  head  of  b’s  request  queue 
and  some  other  philosopher  r  is  b’s  current  requestor,  b  will  demand  the  token  back  from  r  (if 
necessary;  it  may  receive  it  before  making  the  demand)  and  then  send  it  to  q,  which  will  then 
be  b’s  current  requestor.  Finally,  if  q  is  the  head  of  b’s  request  queue  and  b  holds  its  token,  q 
will  become  b’s  current  requestor  (if  no  other  higher  priority  request  arrives  first).  If  no  other 
philosopher  takes  the  highest  priority  away  from  q,  eventually  q  will  be  the  current  requestor 
for  all  its  beverages  and  all  the  tokens  for  those  beverages  will  reach  q.  If  no  demands  are  sent 
in  the  meantime,  which  must  be  the  case  if  q  remains  the  highest  priority  philosopher,  this 
means  that  q  will  drink. 

To  show  that  M(p)  has  a  lower  bound,  we  need  only  examine  its  definition.  Each  held  of 
M{p)  clearly  has  a  lower  bound  of  0:  CD  is  the  maximum  of  an  integer  value  and  0,  PD  is  a  sum 
of  such  maxima,  and  HP  is  the  number  of  processes  in  a  system  that  satisfy  certain  constraints. 
Therefore,  M(p)  has  a  lower  bound  at  (0,  0,  0).  This  completes  the  first  part  of  the  proof. 

From  l  emma  6.7,  we  know  that  M(p )  never  increases.  This  completes  the  second  part  of 
the  proof. 

Finally,  we  need  to  show  that  if  p  does  not  drink  and  does  not  leave  the  system,  M{p) 
eventually  decreases,  and  that  when  M(p)  has  decreased  to  (0,  0,  0),  p  is  guaranteed  to  drink 
or  leave  the  system. 

From  Lemma  6.5,  we  know  that  if  CD(p)  >  0  or  PD(p)  >  0,  M{p)  eventually  decreases 
(because  (CD(p),  PD(p))  eventually  decreases).  Therefore,  if  p  does  not  drink  or  leave  the 
system,  M(p)  will  eventually  become  (0,  0,  k)  for  some  k  >  0. 

When  this  happens,  there  are  k  philosophers  in  the  system  with  higher  priority  than  p 
(by  definition),  and  each  such  philosopher  q  must  have  M(q)  =  (0, 0,  Z),  l  <  k.  This  is  the 
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case  because  q.requestTime  <  p.requestTime  if  q  has  higher  priority  than  p,  and  therefore 
CD(q)  <  CD(p)  and  PD(q)  <  PD(p)  by  definition.  Therefore,  there  must  be  one  philosopher 
r  in  the  system  with  M(r)  =  (0,  0,  0).  This  philosopher  is  guaranteed  to  retain  the  highest 
priority  until  it  drinks  or  leaves  the  system,  because  if  another  philosopher  obtained  higher 
priority,  M(r)  would  have  to  increase,  and  we  have  proven  that  it  cannot  do  so. 

We  have  already  assumed  that  a  philosopher  that  retains  the  highest  priority  long  enough 
eventually  receives  all  its  tokens,  so  philosopher  r  must  eventually  drink  or  leave  the  system. 
When  it  does  either,  HP(p)  decreases.  Therefore,  if  p  does  not  drink  and  does  not  leave  the 
system,  M(p)  eventually  decreases. 

We  have  therefore  shown  both  that  M(p)  eventually  decreases  if  p  does  not  leave  the  system 
and  that  a  philosopher  p  for  which  M(p)  =  (0, 0, 0)  is  guaranteed  to  drink  or  leave  the  system. 
This  completes  the  partial  proof.  □ 
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Chapter  7 

Implementation  of  Dynamic  UNITY 
Systems 


In  this  chapter,  we  present  some  basic  techniques  that  can  be  used  to  transform  Dynamic 
UNITY  programs  and  systems  into  executable  code.  While  our  focus  is  on  the  Java  programming 
language  [30],  the  basic  techniques  presented  are  applicable  to  other  programming  languages 
as  well. 

We  first  describe  the  feasibility  of  implementing  Dynamic  UNITY  systems.  We  then  describe 
a  framework  of  Java  classes  that  provides  the  functionality  of  a  Dynamic  UNITY  runtime  system; 
a  full  implementation  of  this  framework  that  runs  on  a  single  Java  Virtual  Machine  is  found 
in  Appendix  A.  As  an  example  of  system  translation  using  this  framework,  we  present  the 
translation  of  the  simple  Dynamic  UNITY  program  discussed  in  Chapter  2.  A  larger  example, 
the  translation  of  the  single  resource  mutual  exclusion  system  from  Chapter  5,  is  found  in 
Appendix  B. 

7.1  Feasibility 

Many  systems  that  can  be  specified  in  Dynamic  UNITY  can  also  be  successfully  implemented  on 
real  computers,  but  there  exist  two  classes  of  systems  that  cannot  be  implemented.  One  class 
is  comprised  of  those  systems,  such  as  the  prime  number  sieve  described  in  Chapter  4,  that 
would  exceed  any  fixed  amount  of  space  if  allowed  to  run  long  enough  but  that  could  otherwise 
be  implemented.  The  other  class  is  comprised  of  those  systems  that  have  either  malformed  or 
uncomputable  transitions  and  can  therefore  not  be  implemented  at  all.  Malformed  transitions, 
described  in  Section  2.2.6,  either  have  unsatishable  postconditions  or  are  quantified  over  an 
uncountable  range.  Uncomputable  transitions,  described  in  the  same  section,  are  transitions 
whose  guard  or  postcondition  is  uncomputable.  It  is  clear  that  we  cannot  implement  either 
malformed  or  uncomputable  transitions  as  executable  code,  no  matter  what  programming  lan- 
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guage  or  hardware  platform  we  choose. 

For  systems  in  the  former  class,  an  implementation  would  (at  least  potentially)  exhibit  re¬ 
source  usage  that  grows  without  bound,  and  would  therefore  be  of  limited  use.  For  systems  in 
the  latter  class,  we  cannot  create  any  implementation  at  all.  Therefore,  it  is  important  to  deter¬ 
mine  whether  a  Dynamic  UNITY  system  belongs  to  one  of  these  two  classes  before  attempting 
an  implementation. 

This  determination  can  be  made  by  inspecting  the  program  texts  and  correctness  proofs  of 
the  Dynamic  UNITY  system  in  question.  From  the  program  texts  we  can,  in  most  cases,  im¬ 
mediately  determine  whether  or  not  a  system  will  contain  an  infinite  set  of  processes  running 
simultaneously,  create  infinitely  large  data  structures,  or  require  the  computation  of  uncom- 
putable  predicates  during  its  execution.  From  the  correctness  proofs  we  can  determine  whether 
all  the  transitions  of  the  system  have  been  proven  satishable.  Once  we  have  made  this  deter¬ 
mination,  we  may  move  on  to  actually  translating  the  Dynamic  UNITY  system  into  a  set  of  Java 
classes. 

7.2  Translation 

In  order  to  successfully  translate  a  Dynamic  UNITY  system  into  a  set  of  Java  classes,  we  need 
two  important  pieces  of  infrastructure.  The  first  is  a  way  of  instantiating  new  processes.  For 
implementation  on  a  single  Java  Virtual  Machine,  we  can  use  a  Java  thread  to  represent  each 
process,  but  for  implementation  on  a  network  of  Java  Virtual  Machines  we  need  an  underlying 
layer  that  handles  process  instantiation  over  a  network.  The  Caltech  Infospheres  Infrastructure 
[5,  6],  a  preliminary  to  this  work,  is  an  example  of  such  an  underlying  layer  where  the  network 
in  question  is  the  Internet.  Similar  layers  can  be  built  using  core  Java  technologies  such  as  RMI 
and  Object  Activation  [67]  or  any  of  a  number  of  third-party  middleware  products.  We  will 
use  syntax  similar  to  Dynamic  UNITY’S  syntax  for  process  creation,  with  the  justification  that 
we  can  always  implement  a  Java  wrapper  class  that  provides  Dynamic  UNITY  process  creation 
syntax  over  any  underlying  process  creation  infrastructure. 

The  second  required  piece  of  infrastructure  is  a  message  passing  system  that  provides  se¬ 
mantics  equivalent  to  those  of  the  Dynamic  UNITY  message  passing  system.  One  such  system 
is  info.net,  the  messaging  layer  from  the  Infospheres  Infrastructure;  another,  UberNet  [68], 
was  implemented  as  a  preliminary  to  this  work.  Both  of  these  message  passing  systems  im¬ 
plement  first-in  first-out  message  sequencing  between  every  outbox/inbox  pair  (in  the  case 
of  UberNet,  other  message  sequencing  semantics  are  also  available).  Since  the  Dynamic  UNITY 
message  passing  system  does  not  include  the  concept  of  multiple  outboxes  per  process,  we  will 
explicitly  use  a  single  outbox  for  each  process  in  our  Java  translation.  We  will  otherwise  use 
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syntax  similar  to  Dynamic  UNITY’S  syntax  for  messaging  (assuming  again  that  we  can  provide 
appropriate  wrapper  classes  over  any  underlying  infrastructure). 

Once  we  have  the  infrastructure  necessary  for  process  instantiation  and  message  passing, 
we  must  translate  the  Dynamic  UNITY  data  types  into  Java  types  and  classes.  Most  Dynamic 
UNITY  data  types — all  except  array,  inbox,  process,  record  and  multiset— have  direct  ana¬ 
logues  in  the  standard  Java  distribution.  The  Java  classes  Serializable,  Boolean,  Biglnteger, 
BigDecimal,  String,  List  and  Set  are  exactly  analogous  to  Dynamic  UNITY  types  any,  boolean, 
integer,  real,  string,  sequence  and  set.  We  assume  the  existence  of  additional  classes  Inbox 
(part  of  our  wrapper  over  the  messaging  infrastructure),  Process  (part  of  our  wrapper  over  the 
process  creation  infrastructure),  and  Multiset  that  are  analogous  to  the  Dynamic  UNITY  types 
inbox,  process  and  multiset  respectively.  We  implement  each  instance  of  the  Dynamic  UNITY 
record  type  as  a  Java  class  containing  data  members  corresponding  to  those  in  the  record  in¬ 
stance,  and  each  instance  of  the  Dynamic  UNITY  array‘i,m  type  as  a  nested  List  with  dimension 
dim— that  is,  an  array2  would  be  a  List  in  which  every  element  is  a  List. 

Throughout  this  chapter,  we  make  the  assumption  that  the  Java  classes  comprising  Dynamic 
UNITY  programs  and  systems  are  appropriately  packaged;  that  is,  our  classes  are  defined  in  Java 
packages  such  that  their  names  do  not  conflict  with  the  names  of  already-existing  Java  classes. 
We  also  ignore  exception  handling,  scoping  keywords  such  as  private  and  protected,  and 
method  synchronization  primitives.  In  Appendix  A,  we  provide  full,  compilable  source  code 
for  a  complete  set  of  Dynamic  UNITY  runtime  classes.  That  set  of  classes  implements  the 
interfaces  we  describe  in  the  remainder  of  this  chapter,  including  all  exception  handling  and 
other  constructs  required  by  the  Java  language  and  runtime. 

7.2.1  T ranslation  of  T ransitions 

The  translation  of  Dynamic  UNITY  transitions  into  Java  is  straightforward  in  most  cases,  be¬ 
cause  a  typical  transition  will  translate  to  either  an  assignment  statement  or  a  set  of  assignment 
statements.  In  cases  where  nondeterminism  is  present  (disjunction  in  the  postcondition),  any 
implementation — or  a  random  choice  among  multiple  implementations— that  establishes  the 
postcondition  is  acceptable.  The  Dynamic  UNITY  operations  stop  and  send  are  implemented 
with  the  stopO  and  send()  methods  of  Program,  the  base  class  for  Dynamic  UNITY  programs 
discussed  in  the  next  section.  The  creation  of  new  processes  is  implemented  using  a  static 
method  of  the  Process  class  called  i nstanti ate(),  which  takes  as  parameters  a  class  name 
(analogous  to  a  program  name)  and  an  array  of  Serializable  objects  to  be  passed  as  parameters 
to  the  new  process. 
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Example  7.1  (Java  translations  of  Dynamic  UNITY  transitions) 

The  following  are  some  typical  Dynamic  UNITY  transitions,  along  with  one  or  more  translations 
of  each  into  Java.  Note  that  there  may  be  more  valid  translations  for  each  than  are  listed  here. 

1.  A  variable  increment: 
true  — *  x'  =  x  +1 

x  =  x.add(BigInteger .ONE) ; 

2.  A  conditional  variable  increment: 

y>5  — »  x'  =  x  +  1 

if  (y . compareTo(Bi glnteger . val ueOf (5))  >  0) 

{ 

x  =  x.add(BigInteger .ONE) ; 

} 

3.  An  intertwined  variable  increment  (x  and  y  are  integer  variables): 
true  — ►  x'  =  y+  5Ay'  =  x+  5 

Biglnteger  temp  =  x.addfBiglnteger .value0f(5)) ; 
x  =  y.add(BigInteger.value0f(5)) ; 
y  =  temp; 

4.  A  nondeterministic  variable  increment  (x  is  an  integer  variable): 

true  — ►  x'  >  x  +  5 

x  =  x.add(BigInteger.value0f(6)) ; 
x  =  x.add(Math.abs(random.nextInt())  +  5); 

5.  A  message  send  (dest  is  a  variable  of  type  process): 
true  — *  send(dest,  "Vorlon",  "Kosh") 
send(dest,  "Vorlon",  "Kosh"); 

6.  A  guarded  message  receive  (box  is  an  inbox,  msg  is  a  variable  of  type  any): 
box.probe  — *  msg'  =  box.current.msg  A  box.advance 
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if  (box.  probeO) 

{ 

msg  =  box.getCurrentO  .getMessagef)  ; 
box .  advanceQ  ; 


7.  A  process  instantiation  (the  new  process  takes  2  parameters  of  type  any,  and  a  and  b  are 
variables  of  some  type): 

true  — ►  p:  p'  =  new  ExampleProcess(a,  b) 

Seri al i zabl e []  parameters  =  new  Seri al i zabl e [2] ; 
parameters [0]  =  a; 
parameters [1]  =  b; 

Process . i nstanti ate("Exampl eProcess" ,  parameters) ; 

Process . i nstanti ate("Exampl eProcess" ,  new  Seri al i zabl e [2]  {a,  b}) ; 


8.  A  quantihed  transition  (s  is  a  set  of  integers,  its  Java  equivalent  is  a  sorted  set,  and  1  ast 
is  the  most  recent  element  of  the  set  selected  for  execution;  the  method  tai  1  Set(i )  on 
a  sorted  set  s  returns  the  subset  of  s  containing  all  members  of  s  that  are  greater  than 
i): 

<0  i  I  i  <e  s  o  s'  =  s\  {i}) 

if  Cs . i sEmptyO) 

{ 

return ; 

} 

SortedSet  tailSet  =  s . tai 1 Set(l ast . pi us(Bi glnteger . ONE))  ; 
if  Ctai  1  Set .  i  sEmptyO) 

{ 

last  =  (Biglnteger)  s.firstO; 

} 

el  se 

{ 

last  =  (Biglnteger)  tai 1  Set . fi rst() ; 

} 

s . remove(l ast) ; 


7.2.2  Translation  of  Programs 

To  simplify  the  process  of  translating  Dynamic  UNITY  programs,  we  use  a  Java  base  class,  Pro¬ 
gram,  which  includes  functionality  common  to  all  Dynamic  UNITY  programs:  implementations 
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of  stop  and  send  operations  and  execution  of  transitions  from  the  fair-  and  unfair-transitions 
sections.  All  translations  of  Dynamic  UNITY  programs  will  be  subclasses  of  Program.  The  in¬ 
terface  for  the  Program  class  is  as  follows  (all  methods  in  this  interface  are  called  only  by  an 
instantiation  of  a  Program  subclass  on  itself): 

•  void  send(Process  process,  String  inbox,  Serializable  message) enqueues  a 
copy  of  message  for  transmission  to  the  destination  inbox  specified  by  process  and 
inbox.  This  implements  the  send  operation  as  applied  to  a  single  message.  Multiple 
message  sends  are  performed  by  calling  this  method  multiple  times. 

•  void  stopO  stops  the  process’s  execution.  This  implements  the  stop  operation. 

•  Process  getProcessO  returns  the  process’s  reference.  This  implements  the  this  oper¬ 
ation. 

•  voi  d  i  ni  ti  al  i  ze  ()  can  be  overridden  by  subclasses  to  perform  initialization  tasks  (im¬ 
plementing  the  initially-section  of  the  program),  if  necessary. 

•  voi  d  f  ai  rT ransi  ti  on  ()  must  be  overridden  by  subclasses  to  implement  the  fair  transi¬ 
tion  set.  The  implementation  should  pick  one  fair  transition,  in  a  manner  consistent  with 
weak  fairness,  and  execute  it. 

•  void  unfai  rTransitionf)  can  be  overridden  by  subclasses  to  implement  the  unfair 
transition  set,  if  necessary.  The  implementation  should  pick  one  unfair  transition  and 
execute  it. 

•  bool  ean  unfai  rCondi  ti  on  ()  can  be  overridden  by  subclasses  to  implement  a  schedul¬ 
ing  policy  for  unfair  transitions.  It  is  called  every  time  the  process  is  selected  for  execu¬ 
tion;  if  it  returns  true,  an  unfair  transition  is  executed,  and  otherwise  a  fair  transition  is 
executed.  In  order  to  satisfy  Dynamic  UNITY  execution  semantics,  unfai  rCondi  ti  on  () 
must  be  constructed  such  that  it  will  return  false  an  infinite  number  of  times  when  it  is 
called  infinitely  often.  The  default  implementation  always  returns  false  so  that  no  unfair 
transitions  are  ever  executed. 

In  order  to  translate  a  particular  Dynamic  UNITY  program  into  Java,  the  Program  class  must 
be  subclassed.  This  subclass  must  conform  to  the  following  restrictions: 

1.  It  has  a  single  constructor,  which  takes  one  or  two  parameters.  The  first  parameter  is 
always  a  Process  object  and  the  second  parameter,  present  only  for  Dynamic  UNITY  pro¬ 
grams  that  take  parameters,  is  an  array  of  Serializable  objects.  This  constructor  must 
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call  the  superclass  constructor  with  the  Process  object.  The  call  to  the  superclass  con¬ 
structor  allows  the  Program  superclass  to  initialize  itself  properly  by  creating  its  Outbox 
and  keeping  a  record  of  its  associated  Process  object.  If  it  takes  an  array  of  Serializable 
objects  containing  the  parameters  to  the  Dynamic  UNITY  program  as  a  second  parameter, 
the  constructor  must  store  these  objects  in  some  fashion  so  that  they  are  accessible  to 
the  program  when  it  begins  execution. 

2.  If  the  Dynamic  UNITY  program  being  implemented  has  an  initially-section,  it  must  imple¬ 
ment  the  i  ni  ti  al  i  ze  ()  method  in  such  a  way  that  it  initializes  the  Dynamic  UNITY  state 
variables  appropriately. 

3.  Its  fai  rTransitionO  method  is  implemented  such  that  all  the  fair  transitions  of  the 
Dynamic  UNITY  program  are  chosen  in  a  manner  consistent  with  weak  fairness.  One  way 
of  doing  this  is  to  number  the  transitions  and  execute  them  in  a  round-robin  fashion,  so 
that  the  first  time  the  method  is  called  it  executes  transition  0,  the  next  time  it  executes 
transition  1,  etc.  Another  way  of  scheduling  the  transitions  is  to  use  a  pseudorandom 
number  generator  which  is  known  to  be  periodic  and  to  cover  its  range,  and  determine 
the  sequence  of  selected  transitions  from  the  generated  random  number  sequence.  Quan¬ 
tified  transitions  should  generally  be  treated  as  a  single  transition  at  the  fair  transition 
level;  when  a  quantified  transition  is  selected,  its  scheduling  can  be  handled  either  by  se¬ 
lecting  all  the  transitions  in  the  quantification  in  sequence  or  by  selecting  one  in  a  weakly 
fair  manner. 

4.  Its  unf  ai  rT ransi  ti  on  ()  and  unf  ai  rCondi  ti  on  ()  methods  are  implemented  such  that 
the  unfair  transitions  of  the  Dynamic  UNITY  program  are  chosen  in  arbitrary  fashion.  One 
reasonable  translation  for  any  Dynamic  UNITY  program  is  the  translation  which  leaves 
out  the  unfair  transitions  entirely,  since  executions  of  Dynamic  UNITY  programs  never 
have  to  select  unfair  transitions.  Another  reasonable  translation  is  to  turn  the  unfair 
transitions  into  fair  transitions  and  subject  them  to  the  same  weak  fairness  constraint  as 
the  fair  transition  set.  For  robustness  of  possible  execution  sequences,  these  methods 
can  be  implemented  such  that  unfair  transitions  are  chosen  according  to  various  criteria. 
Example  implementations  include  making  unf  ai  rCondi  ti  on  ()  return  true  only  when 
the  current  time  in  milliseconds  from  the  epoch  is  divisible  by  100000,  or  using  a  random 
number  generator  to  determine  whether  an  unfair  transition  gets  executed  at  each  step. 

To  illustrate  the  translation  of  a  complete  Dynamic  UNITY  program,  we  translate  the  pro¬ 
gram  presented  in  Example  2.12  into  Java: 


135 


Example  7.2  (Translation  of  a  single  Dynamic  UNITY  program  to  Java) 

The  original  Dynamic  UNITY  program  is  as  follows: 

program  ExampleSystemComponent 

declare 

theSet:  set  {integer} 

initially 

theSet  =  0 

fair-transition 

(1)  true  — »  (3  i  |  i  <£  theSet  >  theSet'  =  theSet  u  {i}) 

(2)  0  true  — »  stop 

(3)  Q  (Qi  |  i  e  theSet  o  i  >  731  — ►  p:  p'  =  new  ExampleSystemComponent) 

end 

The  program  translated  to  Java  is  seen  below.  We  assume  that  the  necessary  packages 
for  the  Java  classes  we  use  are  properly  imported,  and  that  the  Random  class  implements  a 
pseudorandom  number  generator  which  is  periodic  and  covers  its  range. 

Class  7.1  (A  translation  of  an  example  program) 

public  class  ExampleSystemComponent  extends  Program 

{ 

//  Instance  Variables 

int  transition; 

Biglnteger  last; 

Random  random; 

//  Dynamic  UNITY  Variables 
Set  theSet; 

//  Constructor 

public  Exampl eSystemComponent(Process  process) 

{ 

super (process) ; 

theSet  =  new  TreeSetO; 

last  =  Biglnteger .ZERO; 
random  =  new  Randomf); 
startO  ; 

} 
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//  Instance  Methods 

public  void  fai rTransition() 

{ 

transition  =  Random . nextlnt(3)  ; 

switch  (transition) 

{ 

case  0: 

{ 

Biglnteger  temp  =  new  Bi glnteger (random . nextlntO ,  random); 

while  (theSet . contai ns (temp)) 

{ 

temp  =  new  BigInteger(random.nextInt() ,  random); 

} 

theSet. add(temp) ; 
break ; 

} 

case  1: 

{ 

stop() ; 
break ; 

} 

case  2 : 

{ 

if  (theSet . i sEmptyO) 

{ 

break; 

} 

SortedSet  tailSet  =  theSet . tai 1  Set (1 ast . pi us(Bi glnteger . ONE)) ; 

if  (tai  1  Set . i sEmptyO) 

{ 

last  =  (Biglnteger)  theSet . fi rst() ; 

} 

el  se 

{ 

last  =  (Biglnteger)  tai 1  Set . fi rst() ; 

} 

if  (last.compareTo(BigInteger.valueOf(731))  >  0) 

{ 

Process  newProcess  = 

Process . i nstanti ate("Exampl eSystemComponent") ; 

} 

} 

} 

} 

} 
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We  implement  the  weak  fairness  in  our  fair  transition  section  by  choosing  the  transitions 
according  to  the  sequence  generated  by  our  random  number  generator.  In  our  handling  of 
the  quantified  transition,  we  use  a  Java  class  that  implements  a  sorted  set  ( TreeSet )  and  keep 
track  of  the  most  recent  value  in  the  set  whose  corresponding  transition  was  executed.  This 
allows  us  to  iterate  through  the  set  in  a  fair  manner,  returning  to  the  lowest  value  in  the  set  after 
executing  the  transition  corresponding  to  the  highest.  This  technique  works  well  for  quantified 
transitions  in  general,  provided  that  they  are  quantified  over  data  types  for  which  an  ordering 
relation  exists. 

7.2.3  Translation  of  Systems 

To  simplify  the  process  of  translating  Dynamic  UNITY  systems,  we  use  a  Java  base  class,  Sys¬ 
tem,  which  includes  functionality  common  to  all  Dynamic  UNITY  systems.  Since  a  Dynamic 
UNITY  system  is  comprised  of  a  set  of  a  programs  and  the  labelling  of  one  of  those  programs 
as  “initial,”  the  System  class  is  very  small:  all  it  contains  is  a  constructor  which  instantiates 
the  initial  program  of  a  Dynamic  UNITY  system  (using  the  Process  class).  All  translations  of 
Dynamic  UNITY  systems  will  be  subclasses  of  System  that,  in  their  constructors,  call  the  su¬ 
perclass  constructor  with  the  name  of  the  initial  program  and  the  initial  parameter  list  (if  any). 
A  Dynamic  UNITY  system  is  then  started  by  simply  instantiating  an  object  of  the  appropriate 
class.  Such  subclasses  will  usually  also  contain  a  mai  n()  method,  allowing  them  to  be  started 
directly  from  a  command-line  environment. 

To  illustrate  the  translation  of  a  Dynamic  UNITY  system,  we  translate  the  example  system 
from  Example  2.12,  which  consists  only  of  the  initial  program  ExampleSystemComponent,  into 
Java. 

Example  7.3  (Translation  of  a  Dynamic  UNITY  system  to  Java) 

The  original  Dynamic  UNITY  system  (omitting  the  definition  of  the  component  program)  is  as 
follows: 

system  ExampleSystem 

initial-program  ExampleSystemComponent 

end 


The  system  translated  to  Java  is  as  follows: 
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Class  7.2  (A  translation  of  an  example  system) 

public  class  Exampl eSystem  extends  System 

{ 

//  Constructor 

public  Exampl eSystemO 

{ 

super ( ‘ ‘ Exampl eSystemComponent ’  ’  ,  null); 

} 


More  complex  implementations  of  Dynamic  UNITY  systems  are  possible.  For  example,  it 
might  be  reasonable  to  construct  an  implementation  of  a  system  which  keeps  track  of  all  the 
processes  running  within  it.  However,  more  complex  implementations  are  not  necessary  for 
correctness. 
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Chapter  8 

Related  Work 


In  this  chapter,  we  outline  some  related  work  and  contrast  Dynamic  UNITY  with  some  other 
specification  and  proof  methods  for  distributed  systems. 

8.1  Specification  Methods 

There  are  many  different  approaches  to  the  specification  of  computer  programs,  both  sequen¬ 
tial  and  concurrent.  Some  of  these  form  the  basis  of  our  approach  to  the  specification  of 
dynamic  distributed  systems. 

8.1.1  Axiomatic  Specification 

An  axiomatic  specification  defines  fundamental  language  constructs  by  axioms,  which  are  then 
used  with  inference  rules  to  build  more  complicated  language  constructs.  This  approach  was 
first  used  by  Floyd  [19],  and  has  been  applied  to  sequential  systems  with  great  success.  The 
most  commonly  used  forms  of  axiomatic  specification  for  sequential  programs  are  Hoare  triples 
[25,  26]  and  Dijkstra’s  weakest  preconditions  [16,  17]. 

Axiomatic  specification  has  also  been  applied  to  concurrent  systems.  For  instance,  Mar¬ 
tin  [42]  gave  an  axiomatic  definition  of  synchronization  primitives  in  terms  of  boundedness, 
progress,  and  fairness,  Owicki  and  Cries  [54,  53]  extended  Hoare  triples  with  the  requirement  to 
establish  noninterference  between  threads  of  execution,  and  Lamport  [34]  extended  Dijkstra’s 
weakest  preconditions  with  the  notion  of  weakest  and  strongest  invariants.  Our  assertions 
(described  in  Section  3.1.2)  are  conceptually  similar  to  Hoare  triples. 

Another  method  of  specifications  for  concurrent  systems  is  to  define  the  behavior  of  a 
particular  component  of  the  system  given  that  the  component’s  environment  (the  rest  of  the 
system)  behaves  in  a  specific  way.  That  is,  a  particular  component  is  required  to  behave  cor¬ 
rectly  only  if  all  other  components  in  the  system  also  do  so.  Various  methods  for  specifying 
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component  behavior  in  this  way  have  been  proposed,  including  rely-guarantee  [29],  hypothesis- 
conclusion  [8],  assumption-commitment  [14],  offers-using  [32],  and  assumption-guarantee  [1], 
Each  of  these  methods  imposes  different  restrictions  on  the  types  of  behavior  which  can  be 
specified;  for  instance,  Abadi  and  Lamport’s  assumption-guarantee  approach  restricts  the  as¬ 
sumptions  on  environment  behavior  to  safety  properties  only.  Chandy  and  Sanders’s  “weakest 
guarantee”  method  [9,  10]  considers  requirements  on  the  entire  system  rather  than  just  on 
the  environment  of  a  particular  component.  It  divides  component  properties  into  two  types: 
“exists-component,”  properties  that  hold  for  the  entire  system  if  they  hold  for  a  single  compo¬ 
nent,  and  “all-component,”  properties  that  hold  for  the  entire  system  only  if  they  hold  for  all 
components.  The  properties  we  prove  about  Dynamic  UNITY  programs  “in  isolation”  (that  is, 
in  arbitrary  environments)  are  examples  of  “exists-component”  properties. 

8.1.2  Temporal  Logic 

Temporal  logic  [60,  62]  is  a  branch  of  modal  logic  which  contains  temporal  operators  in  addi¬ 
tion  to  the  standard  propositional  logic  operators  (a,  v,  =>).  The  use  of  temporal  logic  for 
reasoning  about  computer  system  executions  was  first  proposed  by  Kroger  [31]  for  sequential 
systems,  and  by  Pneuli  [58]  for  concurrent  systems.  Computations  are  viewed  as  sequences  of 
global  states,  and  properties  of  the  systems  to  which  these  sequences  correspond  are  speci¬ 
fied  as  temporal  properties  of  the  sequences.  Different  versions  of  temporal  logic  arise  from 
different  formulations  of  the  sets  of  sequences  to  which  the  temporal  operators  apply.  For  ex¬ 
ample,  sequences  may  be  linear  or  branching,  and  may  be  finite  or  infinite.  One  commonly-used 
version,  sometimes  called  Manna-Pneuli  theory  [41,  40],  is  based  on  linear  temporal  logic. 

There  are  multiple  specification  methods  that  incorporate  temporal  logic,  including  UNITY, 
about  which  we  have  already  written  in  detail.  Lamport's  Temporal  Logic  of  Actions  (TLA)  [35] 
is  a  specification  logic  based  on  the  fundamental  temporal  logic  operators  □  (“always”)  and  O 
(“eventually”).  TLA  allows  for  the  specification  of  both  weak  and  strong  fairness  requirements 
(as  well  as  allowing  specifications  without  fairness  requirements),  and  also  allows  for  stutter¬ 
ing  steps  (as  in  UNITY  and  Dynamic  UNITY).  TLA+  [36]  is  a  language  for  the  specification  of 
concurrent  systems  that  uses  TLA  as  its  logical  foundation. 

The  fundamental  operators  of  Dynamic  UNITY  (initially,  next  ,  transient)  are  based  on 
well-known  operators  in  temporal  logic.  The  derived  operators  of  Dynamic  UNITY  (stable, 
invariant,  leads-to)  can  also  be  found  in  many  temporal  logic-based  formalisms,  while  the 
follows  operator  was  originally  presented  by  Sivilotti  [66]. 
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8. 1.2.1  UNITY  Variants 

The  UNITY  language  and  logic  has  been  extended  and  modified  for  various  purposes  since  its 
publication.  One  notable  such  extension  is  Mobile  UNITY  [63,  57],  which  aims  to  use  UNITY- 
based  reasoning  for  systems  with  mobile  processes.  Mobile  UNITY  includes  the  concept,  which 
we  use  in  Dynamic  UNITY,  of  systems  with  component  programs.  It  also  includes  special 
operators  for  specifying  component  locations  and  the  interactions  between  components  which 
share  the  same  location. 

Misra  has  modified  UNITY  since  its  original  publication,  most  notably  replacing  the  safety 
operator  unless  with  co  (which  is  equivalent  to  Dynamic  UNITY’S  next)  [47].  Misra  has  also 
introduced  a  new  multiprogramming  model,  called  Seuss  [48],  which  uses  UNITY  as  its  logical 
foundation. 

8.1.3  Other  Specification  Methods 

The  actor  model  of  computation,  originally  proposed  by  Hewitt  [24]  and  studied  extensively 
by  Agha  [2],  shares  many  characteristics  with  Dynamic  UNITY’S  execution  model.  An  actor  is 
a  computational  agent  which  communicates  with  other  actors  via  fair  asynchronous  message 
passing:  every  actor  has  a  single  “mail  address”  and  a  set  of  actions  that  can  be  executed  in 
response  to  receiving  messages  directed  toward  its  mail  address.  These  actions  can  include  the 
sending  of  messages  to  other  actors  whose  addresses  are  known  and  the  creation  of  new  actors. 
In  addition,  when  receiving  a  message  an  actor  must  always  specify  a  “replacement”— an  actor 
that  will  accept  the  next  incoming  message— that  can  process  the  next  incoming  message  even 
while  the  current  one  is  still  being  processed  by  the  original  actor.  Concurrency  in  the  actor 
model  arises  from  the  sending  of  multiple  messages  in  response  to  a  single  incoming  message, 
and  from  the  simultaneous  handling  of  messages  by  actors  and  their  replacements. 

There  are  several  key  differences  between  actor  computations  and  Dynamic  UNITY  execu¬ 
tions:  communication  in  Dynamic  UNITY  is  more  flexible,  allowing  multiple  inboxes  per  process 
instead  of  a  single  mail  address;  execution  in  Dynamic  UNITY  consists  of  atomic  transitions, 
which  makes  it  unnecessary  to  explicitly  handle  race  conditions  and  similar  concurrency  issues; 
execution  of  transitions  in  Dynamic  UNITY  occurs  continually  according  to  a  weak  fairness  re¬ 
quirement,  rather  than  solely  in  response  to  incoming  messages;  and  Dynamic  UNITY  processes 
can  remove  themselves  from  a  running  system  during  execution. 

Milner’s  Calculus  for  Communicating  Systems  (CCS)  [43]  is  an  algebraic  process  calculus 
for  the  specification  of  systems  of  communicating  processes.  The  Tt-calculus  [44,  45]  is  a 
generalization  of  CCS  that  allows  the  description  of  processes  whose  communication  links 
change  during  execution,  which  makes  it  well  suited  to  the  description  of  systems  with  mobile 
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components. 

I/O  automata  [39,  38]  model  interacting  distributed  system  components  by  simple  state 
machines  in  which  the  transitions  are  associated  with  named  actions.  These  actions  can  be 
input  actions,  output  actions,  or  internal  actions.  The  first  two  are  used  for  communication 
with  an  automaton’s  environment,  while  the  last  is  used  for  state  changes  within  the  automaton 
itself.  I/O  automata  are  similar  to  Dynamic  UNITY  programs,  in  that  they  contain  local  state 
and  transitions.  However,  the  I/O  automata  model  does  not  allow  for  the  dynamic  instantiation 
and  destruction  of  automata,  nor  for  changes  in  the  communication  patterns  of  already-existing 
automata  analogous  to  inbox  creation. 

8.2  Communication  Models 

Various  communication  models  have  been  used  to  design  and  reason  about  systems  of  commu¬ 
nicating  processes.  Hoare’s  Communicating  Sequential  Processes  (CSP)  [26,  27]  is  a  widely  used 
model  in  which  processes  communicate  via  synchronous  channels  (with  one  channel  connect¬ 
ing  each  pair  of  processes).  A  process  sending  a  message  to  another  process  blocks  until  the 
other  process  executes  a  receive  action,  and  vice  versa.  Misra  and  Chandy  [49]  used  a  variant  of 
this  model  (with  communications  addressed  to  channels  rather  than  to  processes)  to  present 
a  proof  method  for  networks  of  processes. 

Generative  communication  [21]  is  the  model  of  communication  that  underlies  the  Linda  [20] 
distributed  programming  language.  In  this  model,  messages  are  added  as  named  tuples  to  a 
shared  “tuple  space”  where  they  remain  until  a  process  receives  them.  Among  the  applications 
that  have  been  implemented  in  Linda  since  its  introduction  is  Lime  [56],  a  system  for  developing 
mobile  applications  whose  formal  semantic  definition  has  been  verified  using  Mobile  UNITY. 

The  follows  operator,  introduced  by  Sivilotti  [66],  is  a  natural  choice  for  characterizing  the 
behavior  of  asynchronous  message  passing  systems  upon  which  we  have  relied  heavily  in  the 
definition  of  the  Dynamic  UNITY  message  passing  system.  A  similar  operator,  the  observation, 
is  presented  by  Charpentier  [12,  13]. 

Brock  and  Ackerman  [4]  present  a  proof  that  history  relations  (relations  from  input  se¬ 
quences  to  output  sequences  for  message-passing  processes)  are  insufficient  to  characterize 
the  behavior  of  non-determinate  message  passing  processes;  they  show  that  temporal  relation¬ 
ships  between  input  messages  and  output  messages  must  also  be  considered  when  character¬ 
izing  process  behavior.  Our  proofs  use  such  temporal  information,  primarily  in  the  form  of 
follows  properties,  to  characterize  the  behavior  of  Dynamic  UNITY  processes. 


143 

8.3  “Stop”  as  a  Failure  Model 

Various  models  have  been  proposed  to  reason  about  the  behavior  of  computer  systems  which 
exhibit  failures.  Though  we  have  not  explicitly  addressed  failure  models,  the  stop  command  in 
the  Dynamic  UNITY  language  is  similar  to  a  particular  failure  model,  Schlicting  and  Schneider’s 
[64]  “fail-stop  processor.”  A  fail-stop  processor  automatically  halts  execution  in  the  presence 
of  a  failure,  before  that  failure  becomes  visible  to  external  observers,  and  allows  execution 
to  be  restarted  on  a  working  processor.  The  “volatile”  storage  of  a  fail-stop  processor  is  lost 
during  a  failure,  while  the  “stable”  storage  is  unaffected.  In  contrast,  the  volatile  state  of  a 
Dynamic  UNITY  process  can  be  changed  by  the  message-passing  system  after  a  stop  occurs, 
while  its  non-volatile  state  remains  unchanged.  There  is  no  way  to  restart  a  stopped  process 
in  the  current  Dynamic  UNITY  language,  so  Dynamic  UNITY’S  stop  does  not  completely  model 
a  fail-stop  processor.  However,  it  can  be  used  as  a  starting  point  for  defining  such  a  model. 
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Chapter  9 

Conclusion 

9.1  Summary 

In  this  thesis  we  have  described  Dynamic  UNITY,  a  new  specification  language  and  proof  logic 
for  dynamic  distributed  systems.  Our  language  and  logic  are  extensions  to  the  established 
UNITY  formalism,  which  enables  us  to  apply  proof  techniques  developed  for  UNITY  in  our 
correctness  proofs.  In  creating  Dynamic  UNITY,  we  made  the  following  changes  to  the  UNITY 
language  and  proof  logic: 

•  We  introduced  modularity,  by  making  programs  components  of  larger  systems  rather 
than  complete  system  specifications.  This  allows  programs  to  be  used  as  parts  of  various 
distinct  systems,  without  any  changes  to  their  specifications  or  proofs  of  correctness. 

•  We  added  the  ability  for  processes  to  create  new  processes,  and  to  destroy  themselves, 
at  execution  time.  This  enables  us  to  design  dynamic  systems,  which  adapt  to  changing 
conditions  or  requirements  during  their  execution,  in  an  intuitive  fashion. 

•  We  eliminated  shared  variables  entirely,  providing  a  measure  of  information  hiding  for 
programs.  This  makes  it  possible  to  prove  both  safety  and  progress  properties  of  a  pro¬ 
gram  that  hold  for  every  possible  instantiation  of  that  program  regardless  of  the  behavior 
of  external  processes.  This  facilitates  the  construction  of  modular  correctness  proofs  for 
complex  systems. 

•  We  introduced  a  reliable  asynchronous  message  passing  layer,  as  an  integral  part  of  the 
new  execution  model.  This  eliminates  the  need  for  system  architects  to  simulate  message 
channels  with  history  variables,  queues,  or  other  mechanisms,  and  therefore  simplifies 
the  construction  of  complex  systems. 

•  We  changed  the  notation  for  state  transitions  from  guarded  parallel  assignment  state¬ 
ments  to  guarded  binary  predicates.  This  adds  some  flexibility  to  the  language,  and  al- 
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lows  us  to  focus  on  the  desired  results  of  transition  statements  rather  than  on  the  precise 
set  of  assignment  statements  required  to  bring  about  those  results.  It  also  allows  us  to 
more  easily  and  intuitively  incorporate  nondeterministic  behavior  into  our  designs. 

We  have  demonstrated  the  utility  of  Dynamic  UNITY  by  designing  and  proving  the  correct¬ 
ness  of  two  example  systems  based  on  well-known  algorithms— an  infinite  prime  number  sieve 
and  a  single  resource  mutual  exclusion  system.  As  an  example  of  a  more  complex  distributed 
systems  problem,  we  presented  a  new,  dynamic  variant  of  the  drinking  philosophers  problem; 
we  then  designed  and  partially  proved  an  example  system  that  solves  this  problem.  All  three 
of  these  example  systems  are  dynamic,  with  component  processes  that  enter  and  leave  the 
system  at  runtime. 

We  have  also  presented  a  method  for  determining  whether  a  given  Dynamic  UNITY  specifica¬ 
tion  can  be  transformed  into  an  actual  implementation  in  a  standard  programming  language, 
and  a  method  for  transforming  those  specifications  that  can.  This  makes  Dynamic  UNITY  a 
practical  language  for  programming  dynamic  distributed  systems,  since  a  correct  implementa¬ 
tion  can  be  guaranteed  for  any  implementable  Dynamic  UNITY  system. 

9.2  Future  Directions 

There  are  many  possible  avenues  of  research  to  be  pursued  as  extensions  to  this  work.  All  of 
them  build  on  the  formalism  we  have  defined,  and  further  our  goal  of  enabling  the  construction 
of  correct  dynamic  distributed  systems. 

First,  we  could  design  and  implement  a  compiler  capable  of  transforming  implementable 
Dynamic  UNITY  specifications  into  either  straight  executable  code  or  code  in  another  high- 
level  language  (such  as  Java).  This  would  allow  system  designers  to  prototype  in  Dynamic 
UNITY  directly,  and  then  later  to  perform  optimizations  on  the  implementations  generated 
by  the  compiler.  It  would  also  ensure  the  correctness  of  the  generated  implementations  by 
eliminating  the  possibility  of  human  error  in  code  transformation. 

Another  possibility  is  to  implement  tools  to  assist  in  formulating  correctness  proofs  of 
Dynamic  UNITY  systems.  Theorem  proving  tools  and  environments,  such  as  HOL  [22],  Coq 
[61],  Isabelle  [55]  and  Nuprl  [15],  might  be  useful  as  a  basis  for  such  implementation.  In  fact, 
some  work  on  proving  the  correctness  of  UNITY  systems  using  these  tools  has  already  been 
done  (such  as  HOL-UNITY  [3]).  Such  tools  would  be  very  helpful,  both  by  assisting  in  proof 
formulation  and  in  checking  the  validity  of  previously  existing  proofs. 

There  is  also  the  possibility  of  using  Dynamic  UNITY  to  carry  out  proofs  for  programs  in 
other  high-level  programming  languages  (such  as  C++  or  Java).  We  have  already  demonstrated 
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the  translation  of  Dynamic  UNITY  programs  to  code  in  high-level  languages,  but  translation  in 
the  other  direction  is  potentially  even  more  useful.  However,  significant  difficulties  may  arise 
in  performing  this  translation,  such  as  dealing  with  complex  control  structures  and  exception 
handling  mechanisms. 

Other  possibilities  arise  when  we  consider  potential  future  modifications  to  Dynamic  UNITY 
itself.  These  can  be  roughly  divided  into  two  categories:  modifications  which  aid  the  construc¬ 
tion  and  proof  of  large  systems,  and  modifications  which  add  capabilities  to  the  Dynamic  UNITY 
language  itself. 

In  the  first  category,  we  could  introduce  the  ability  to  construct  systems  hierarchically,  by 
building  “subsystems”  comprised  of  a  set  of  programs  and  a  set  of  exported  mailboxes.  Just 
as  with  programs,  we  could  prove  safety  and  progress  properties  about  these  subsystems  in 
arbitrary  environments,  and  then  integrate  them  into  larger  subsystems  or  top-level  systems. 
We  could  also  devise  a  method  for  refinement,  which  would  allow  us  to  prove  that  particular 
Dynamic  UNITY  specifications  are  refinements  of  other,  higher-level  specifications  (and  vice- 
versa). 

In  the  second  category,  we  could  introduce  the  object-oriented  notion  of  inheritance,  giving 
the  ability  for  programmers  to  extend  existing  Dynamic  UNITY  programs  while  preserving  some 
or  all  of  their  safety  and  progress  properties.  We  could  also  introduce  a  stronger  type  system, 
including  typing  of  inboxes,  which  would  allow  programmers  to  worry  less  about  receiving 
messages  of  unexpected  types  from  the  environment  and  therefore  reduce  the  work  involved 
in  proving  the  behavior  of  programs  in  arbitrary  environments. 


147 


Appendix  A 

Java  Implementation  of  a  Dynamic 
UNITY  Runtime  Framework 


The  following  Java  classes  comprise  a  complete  Dynamic  UNITY  runtime  framework  that  runs 
in  a  single  Java  Virtual  Machine.  It  implements  the  interface  described  in  Chapter  7,  and  can 
be  used  to  build  the  example  programs  in  that  chapter  and  in  Appendix  B. 

This  runtime  implementation  does  not  use  true  asynchronous  messaging;  instead,  it  sim¬ 
ulates  asynchronous  messaging  by  setting  explicit  arrival  times  for  messages  delivered  to  in¬ 
boxes.  This  is  done  primarily  for  efficiency;  since  all  the  messages  are  staying  within  the  same 
Java  Virtual  Machine,  it  is  more  efficient  to  simufate  asynchronous  defivery  than  to  actuaiiy  use 
additionai  Java  threads  to  impiement  true  asynchronous  delivery. 

The  following  sections  each  contain  one  of  the  seven  classes  that  comprise  the  runtime 
system,  with  a  brief  description  of  the  class  functionality.  The  Javadoc  comments  for  these 
classes  have,  for  the  most  part,  been  left  in  the  source  code.  This  provides  documentation  for 
the  actual  implementation  choices  that  have  been  made. 

A.  1  System 

System  is  the  base  class  for  translations  of  Dynamic  UNITY  systems.  It  implements  the  func¬ 
tionality  described  in  Section  7.2.3. 

Class  A.i  ( System ,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java. io. Serializable; 

public  class  System 

{ 


//  Constructors 
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public  System(Stri ng  i ni ti al Program ,  Seri al i zabl e []  i ni ti al Parameters) 

{ 

Process . i nstanti ate(i ni ti al Program ,  i ni ti al Parameters) ; 

} 


public  System(Stri ng  i ni ti al Program) 

{ 

thi  s (i ni ti al Program ,  null); 

} 


A.2  Process 


Process  is  the  class  that  encapsulates  a  Dynamic  UNITY  process  identifier.  It  also  includes 
utility  methods  for  the  creation  and  destruction  of  processes. 

Class  A.2  ( Process ,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java.io. Serializable; 
import  java.lang. refl ect . Constructor ; 
import  java. util .Collections; 
import  java. util .HashMap; 
import  java. util .Map; 

public  class  Process  implements  Serializable 

{ 

//  Static  Variables 

/** 

*  An  empty  array  of  Serializable,  used  when  constructing  new  processes. 

**/ 

public  static  final  Seri al i zabl e []  EMPTY_SERIALIZABLE_ARRAY  = 
new  Seri al i zabl e [0] ; 


/** 

*  A  map  from  the  system’s  process  references  to  threads. 

**/ 

private  static  Map  processTable  = 

Col  1  ecti ons . synch roni zedMapfnew  HashMap O) ; 


/** 

*  A  map  from  the  system’s  threads  to  process  references. 

**/ 
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private  static  Map  threadTable  = 

Col  1  ecti  ons  .  synch  roni  zedMapCnew  HashMapQ)  ; 


/** 

*  An  integer  value  used  to  create  unique  process  names. 

**/ 

private  static  i nt  processIDUni quenessVal ue  =  0; 


//  Instance  Variables 

/** 

*  The  ID  string  for  this  Process. 

**/ 

private  String  id; 


//  Static  Methods 


Creates  a  new  Dynamic  UNITY  process  from  the  specified  Dynamic  UNITY 
program  with  the  specified  instantiation  parameters,  and  returns  a 
Process  object  identifying  it. 

@param  programName  The  fully  qualified  lava  class  name  of  the  class 
that  implements  the  Dynamic  UNITY  program  to  be  instantiated. 

©param  parameters  An  array  of  Serializable  values  to  be  used  as 
instantiation  parameters. 

©return  a  Process  object  identifying  the  new  process,  or  null  if 
something  went  wrong  during  the  instantiation  of  the  new  process. 


©concurrency  (GUARDED) 

V 


public  synchronized  static  Process 

i nstanti ate(Stri ng  programName,  Seri al i zabl e []  parameters) 

{ 

try 

{ 

Class  programClass  =  Cl  ass . forName(programName) ; 

Constructor []  constructors  =  programCl ass . getConstructorsO ; 
Program  newProgram  =  null; 

Process  newProcessID  =  getUni queProcessIDO ; 

Object[]  real  Parameters ; 

if  (parameters  ==  null) 

{ 

real  Parameters  =  new  Object [1]; 
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real  Parameters  [0]  =  newProcessID ; 

} 

el  se 

{ 

real  Parameters  =  new  0bject[2]; 
real  Parameters  [0]  =  newProcessID; 
real  Parameters  [1]  =  parameters; 

} 

for  (int  1  =  0;  i  <  constructors . 1 ength ;  i++) 

{ 

//  try  all  the  constructors;  there  really  should  be  only  one 

try 

{ 

newProgram  = 

(Program)  constructors [i ] . newlnstance(real Parameters) ; 

} 

catch  (Exception  ex) 

{ 

ex . pri ntStackT  race() ; 

} 

} 

if  (newProgram  !=  null) 

{ 

//  we  created  a  new  process,  add  it  to  the  table  and  run  it 

Thread  newThread  =  new  Thread(newProgram) ; 
processTabl e . put (newProcessID ,  newThread) ; 
threadTabl e . put (newThread ,  newProcessID) ; 
newTh  read . start  () ; 
return  newProcessID; 

} 

el  se 

{ 

return  nul 1  ; 

} 

} 

catch  (Exception  e) 

{ 

e . pri ntStackT  race() ; 
return  nul 1  ; 

} 

} 


Creates  a  new  Dynamic  UNITY  process  from  the  specified  Dynamic  UNITY 
program  with  no  instantiation  parameters,  and  returns  a  Process 
object  identifying  it. 

Oparam  programName  The  fully  qualified  lava  class  name  of  the  class 
that  implements  the  Dynamic  UNITY  program  to  be  instantiated. 
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*  ©return  a  Process  object  identifying  the  new  process,  or  null  if 

*  something  went  wrong  during  the  instantiation  of  the  new  process. 

*  ©concurrency  (GUARDED) 

**/ 

public  synchronized  static  Process  i nstanti ate(Stri ng  programName) 

{ 

return  i nstanti ate(programName ,  null); 

} 


Destroys  a  Dynamic  UNITY  process  by  removing  it  from  the  process  table 
and  notifies  the  Inbox  class  of  the  process’s  destruction.  If  the 
specified  process  has  already  been  destroyed,  this  method  has  no 
effect . 


©param  The  Process  object  identifying  the  process  to  be  destroyed. 

V 


static  void  destroy(Process  process) 

{ 

threadTabl e . remove (processTabl e . get (process)) ; 
processTabl e . remove(process) ; 

Inbox . remove Process (process) ; 

} 


/** 

*  ©return  an  unmodifiable  view  of  the  process  table.  This  is  for  use 

*  primarily  by  the  Inbox  class. 

**/ 

static  Map  getProcessTable() 

{ 

return  Col  1 ecti ons . unmodi fi abl eMap(processTabl e) ; 

} 


/** 

*  ©return  an  unmodifiable  view  of  the  thread  table.  This  is  for  use 

*  primarily  by  the  Inbox  class. 

**/ 

static  Map  getThreadTabl e() 

{ 

return  Col  1 ecti  ons . unmodi f i abl eMap (threadTabl e) ; 

} 


/** 

*  ©return  a  new  unique  process  ID. 

**/ 
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private  static  Process  getUni queProcessIDO 

{ 

Process  processID  = 

new  Process(java. 1 ang . System . cur rentTimeMi 11 i s()  + 

+  processIDUni quenessVal ue) ; 

if  (processIDUni quenessVal ue  <  Integer . MAX_VALUE  -  1) 

{ 

processIDUni quenessVal ue  =  processIDUni quenessVal ue  +  1; 

} 

el  se 

{ 

processIDUni quenessVal ue  =  0; 

} 

return  processID; 

} 


//  Constructor 


/* 


* 


Constructs  a  new  Process  object  with  the  specified  process  identifier. 

@param  id  The  process  identifier. 

*/ 


private  Process(Stri ng  id) 

{ 

thi s . i d  =  id; 

} 


//  Inherited  Instance  Methods 

/** 

*  ©return  a  hash  code  for  this  object. 

**/ 

public  int  hashCodeO 

{ 

return  i d .  hashCodeO  ; 

} 


/** 

*  ©return  true  if  this  object  is  equivalent  to  the  specified  object, 

*  false  otherwise. 

**/ 

public  boolean  equals(0bject  object) 

{ 

if  ((object  !=  null)  &&  (object . getCl ass() . equal s (thi s . getCl ass()))) 


153 


{ 

Process  otherProcess  =  (Process)  object; 

if  (id  ==  null) 

{ 

return  (otherProcess . i d  ==  null); 

} 

el  se 

{ 

return  (i d . equal s (other Process .id)); 

} 

} 

el  se 

{ 

return  false; 

} 

} 


//  No  Instance  Methods 

} 


A.  3  Program 

Program  is  the  base  class  for  translations  of  Dynamic  UNITY  programs,  implementing  the 
interface  described  in  Section  7.2.2.  This  implementation  relies  on  certain  features  of  Java  and 
the  message  passing  system,  and  on  the  implementor  of  its  subclasses,  to  ensure  that  weak 
fairness  is  maintained  in  the  translation  of  a  Dynamic  UNITY  program.  Specifically,  it  relies  on 
the  fact  that  Java  chooses  threads  for  execution  from  a  run  queue  and  so,  if  all  threads  contain 
appropriately-placed  yi  el  d  ()  statements,  no  thread  will  ever  be  starved  for  execution  time.  It 
also  relies  on  the  fairness  of  the  message  passing  system — all  sent  messages  must  be  delivered 
to  their  destinations  in  finite  time  assuming  that  the  destinations  exist. 

Class  A.3  ( Program ,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java. io. Serializable; 

public  abstract  class  Program  implements  Runnable 

{ 

//  Instance  Variables 

/** 

*  A  flag  indicating  whether  or  not  this  instantiation  of  the  Program 

*  is  running. 

**/ 
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private  boolean  running; 


/** 

*  The  Outbox  used  by  this  instantiation  of  the  Program. 

**/ 

private  Outbox  outbox; 


/** 

*  The  Process  reference  corresponding  to  this  instantiation  of  the 

*  Program. 

**/ 

private  Process  process; 


//  Constructor 

public  ProgramCProcess  process) 

{ 

this. process  =  process; 
outbox  =  new  Outbox(process) ; 
running  =  true; 

} 


//  Inherited  Instance  Methods 

/** 

*  The  main  run  loop  of  a  Dynamic  UNITY  process. 

**/ 

public  void  run() 

{ 

i ni ti al i ze() ; 

while  (running) 

{ 

if  (unfai  rConditionO) 

{ 

unfai  rTransitionO  ; 

} 

el  se 

{ 

f  ai  rT ransi  ti  on  ()  ; 

} 

Thread.yieldO  ; 

} 

} 
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//  Instance  Methods 

/** 

*  Sends  a  message  on  the  outbox.  This  implements  the  Dynamic  UNITY 

*  send  operation. 

**/ 

protected  void  send(Process  process,  String  inbox,  Serializable  message) 

{ 

outbox. send(process ,  inbox,  message); 

} 


/** 

*  Stops  the  execution  of  this  instantiation  of  the  Program. 

**/ 

protected  void  stop() 

{ 

running  =  false; 

Process . destroy (process) ; 

} 


/** 

*  ©return  true  if  this  instantiation  of  the  Program  is  running, 

*  and  false  if  it  has  been  stopped. 

**/ 

public  boolean  isRunningO 

{ 

return  running; 

} 


/** 

*  ©return  the  Process  object  associated  with  this  instantiation  of  the 

*  Program. 

**/ 

public  Process  getProcessO 

{ 

return  process; 

} 


/** 

*  An  abstract  method  that  must  be  overridden  by  subclasses  to  implement 

*  initialization.  This  method  should  assign  initial  values  to  variables, 

*  as  appropriate. 

**/ 


protected  abstract  void  i ni ti al i ze() ; 
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/** 

*  An  abstract  method  that  must  be  overridden  by  subclasses  to  implement 

*  the  fair  transition  set.  This  method  should  pick  one  fair  transition 

*  in  a  manner  consistent  with  weak  fairness  and  execute  it. 

**/ 

protected  abstract  void  fai  rTransitionQ  ; 


/** 

*  A  method  with  no  body  that  can  be  overridden  by  subclasses  to 

*  implement  the  selection  of  unfair  transitions.  If  overridden,  this 

*  method  should  select  a  single  unfair  transition  and  execute  it. 

**/ 

protected  void  unfai  rTransitionQ  {} 


/** 

*  A  method  that  can  be  overridden  by  subclasses  to  determine  the 

*  scheduling  policy  for  unfair  transitions.  This  method  is  called  every 

*  time  through  the  main  run  loop.  If  it  returns  true,  an  unfair 

*  transition  is  executed;  otherwise,  a  fair  transition  is  executed.  It 

*  should  therefore  return  false  most  of  the  time.  By  default,  it  always 

*  returns  false  (meaning  that  no  unfair  transitions  are  ever  executed). 
**/ 

protected  boolean  unfai rConditi on () 

{ 

return  false; 

} 


A.  4  Outbox 


Outbox  is  the  class  that  handles  sending  messages  within  a  Dynamic  UNITY  system.  As  men¬ 
tioned  previously,  we  simulate  asynchronous  message  delivery  by  explicitly  placing  timestamps 
on  messages.  The  Outbox  implementation  is  responsible  for  adding  these  timestamps,  and  en¬ 
sures  that  messages  sent  from  the  same  Outbox  instance  have  monotonically  increasing  time- 
stamps. 

Class  A.4  ( Outbox ,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java.io. Serializable; 
import  java. uti 1 . Random ; 
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class  Outbox 

{ 

//  Static  Variables 

/** 

*  The  maximum  message  delivery  delay,  in  milliseconds. 

**/ 

static  final  int  MAX_DELAY  =  10000; 


/** 

*  The  minimum  delay  between  message  deliveries,  in  milliseconds. 

**/ 

static  final  int  MIN_DELAY  =  10; 


//  Instance  Variables 

/** 

*  The  process  to  which  this  Outbox  belongs. 

**/ 

private  Process  process  =  null; 


/** 

*  The  last  timestamp  that  was  attached  to  a  message  sent  by  this 

*  Outbox. 

**/ 

private  long  1 astTimestamp  =  0; 


/** 

*  The  random  number  generator  used  by  this  Outbox. 

**/ 

private  Random  random  =  new  RandomQ ; 


//  Constructor 


/* 


* 


Constructs  a  new  Outbox  belonging  to  the  specified  process. 


@param  process  The  process. 

V 


0utbox(Process  process) 

{ 

this. process  =  process; 


} 
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//  Instance  Methods 


Sends  a  message  with  the  specified  contents  to  the  specified  inbox 
of  the  specified  process. 

Oparam  process  The  destination  process. 

@param  inbox  The  name  of  the  destination  inbox. 

@param  message  The  message  contents. 


©concurrency  (GUARDED) 

V 


synchronized  void  send 

(Process  destination,  String  inbox,  Serializable  message) 

{ 

int  delay  =  random. nextInt(MAX_DELAY) ; 
long  timestamp  = 

Math . max (java. 1 ang . System . cur rentTimeMi 1 1 i s()  +  delay, 

1 astTimestamp  +  MIN_DELAY) ; 

1 astTimestamp  =  timestamp; 

Message  packagedMessage  =  new  Message(process ,  message,  timestamp); 
Inbox . del i ver(desti nati on ,  inbox,  packagedMessage); 

} 

} 


A.  5  Inbox 


Inbox  is  the  class  that  handles  message  delivery  queues  in  a  Dynamic  UNITY  system.  The  Inbox 
implementation  guarantees  that  messages  are  received  roughly  in  order  of  their  timestamps. 
More  precisely,  it  guarantees  that  the  current  message  is  always  the  delivered  message  with  the 
earliest  timestamp,  but  not  that  there  are  no  undelivered  messages  with  earlier  timestamps. 
This  satisfies  the  hrst-in  first-out  requirement  for  all  outbox-inbox  pairs,  since  no  outbox  ever 
sends  messages  with  out-of-order  timestamps. 

Class  A.5  (Inbox,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java. util .ArrayList; 
import  java. util .Collections; 
import  java. util .HashMap; 
import  java. uti 1 . Li st ; 
import  java. util .Map; 
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public  class  Inbox 

{ 

//  Static  Variables 

/** 

*  A  map  from  process  references  to  maps  from  inbox  names  to  Inbox 

*  objects. 

**/ 

private  static  Map  i nboxMapTabl e  = 

Col  1  ecti  ons  .  synch  roni  zedMap(new  HashMapO)  ; 


//  Instance  Variables 

/** 

*  The  List  of  messages  in  this  Inbox. 

**/ 

private  List  messageList  =  new  ArrayListC); 


/** 

*  The  message  pointer  of  this  Inbox. 

**/ 

private  int  messagePoi nter  =  0; 


//  Static  Methods 


Delivers  a  message  to  the  Inbox  with  the  specified  name  belonging  to 
the  specified  process.  If  the  specified  process  exists  but  does  not 
have  an  Inbox  with  the  specified  name,  one  is  created.  If  the 
specified  process  does  not  exist  in  the  system,  the  message  is 
di scarded . 


Oparam  destination  The  destination  process. 
Oparam  inboxName  The  destination  inbox  name. 
Oparam  message  The  message. 

V 


static  void  deliver 

(Process  destination,  String  inboxName,  Message  message) 

{ 

i f  (Process . getProcessTabl e() . contai nsKey(desti nati on)) 

{ 

Map  inboxMap; 

Inbox  inbox; 

synchronized  (i nboxMapTabl e) 

{ 

inboxMap  =  (Map)  i nboxMapTabl e . get (desti nation) ; 


160 


if  (inboxMap  ==  null) 

{ 

inboxMap  =  Col  1  ections  .  synchroni zedMap(new  HashMapO); 
i nboxMapTabl e . put (desti nati on ,  i  nboxMap) ; 

} 

} 

synchronized  (inboxMap) 

{ 

inbox  =  (Inbox)  i nboxMap . get(i nboxName) ; 

if  (inbox  ==  null) 

{ 

inbox  =  new  Inbox(desti nation ,  i nboxName); 

} 


inbox. enqueue(message) ; 

} 


} 


/* 


* 


Removes  a  process’s  inboxes  from  the  system. 
Oparam  process  The  process. 

V 


static  void  removeProcess (Process  process) 

{ 

i  nboxMapTabl e . remove(process) ; 

} 


//  Constructors 


Constructs  a  new  Inbox  with  the  specified  name  belonging  to  the 
process  whose  thread  calls  the  constructor.  If  an  Inbox  with  the 
specified  name  already  exists  for  this  process,  the  constructed  Inbox 
is  an  exact  duplicate  of  it. 


Oparam  name  The  inbox  name. 

©exception  SecurityException  if  the  thread  calling  this  constructor 
is  not  known  to  the  Dynamic  UNITY  runtime. 

V 


public  Inbox(String  name) 

throws  II 1 egal ArgumentException 

{ 

Map  threadTable  =  (Map)  Process . getThreadTabl e() ; 

Process  process  =  (Process)  threadTabl e .  get(Thread .  cur rentThreadQ)  ; 
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if  (process  ==  null) 

{ 

throw  new  SecurityException 

("Inbox  constructor  called  from  unknown  thread."); 

} 

synchronized  (i nboxMapTabl e) 

{ 

Map  inboxMap  =  (Map)  i nboxMapTabl e . get(process) ; 

if  (inboxMap  !=  null) 

{ 

synchronized  (inboxMap) 

{ 

Inbox  oldlnbox  =  (Inbox)  i nboxMap . get(name) ; 

if  (oldlnbox  !=  null) 

{ 

thi s . messageLi st  =  ol dlnbox . messageLi st ; 

} 

inboxMap. put (name,  this); 

} 

} 

el  se 

{ 

inboxMap  =  Col  1  ecti ons  . synchroni zedMap(new  HashMapO); 
i nboxMap . put(name ,  this); 
i nboxMapTabl e . put(process ,  i nboxMap) ; 

} 

} 

} 


Constructs  a  new  Inbox  with  the  specified  name  belonging  to  the 
specified  process.  It  is  assumed  that  the  process  already  exists, 
that  no  Inbox  with  the  specified  name  exists  for  the  process,  and 
that  the  calling  thread  holds  locks  for  both  the  inbox  map  table  and 
the  process’s  inbox  map. 

This  method  is  only  called  by  the  Inbox  class. 


Oparam  process  The  process. 
Oparam  name  The  inbox  name. 

V 


private  Inbox(Process  process,  String  name) 

{ 

i nboxMapTabl e . put(name ,  this); 

} 
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//  Instance  Methods 


/* 


* 


Enqueues  a  message  in  this  Inbox, 
the  Inbox  class. 

©param  message  The  message. 

©concurrency  (GUARDED) 

V 


This  method  is  only  called  by 


private  synchronized  void  enqueue(Message  message) 

{ 

messageLi st . add(message) ; 

Col 1 ecti ons . sort (messageLi st) ; 


/* 


* 


©return  true  if  there  is 
read  from  this  Inbox. 

©concurrency  (GUARDED) 

V 


at  least  one  message  waiting  to  be 


public  synchronized  boolean  probe() 

{ 

while  ((messagePoi nter  >  0)  &&  (messageLi st . si ze()  >  0)) 

{ 

messageLi st . remove(O) ; 

messagePoi nter  =  messagePoi nter  -  1; 


return  ((messageLi st . si ze()  >  0)  && 

(((Message)  messageLi st . get (0)) . ti mestampO  <= 
java . 1 ang . System . currentTi meMi 1 1 i s () ) ) ; 


©return  the  current  message  from  this  Inbox.  If  there  is  no 
current  message  (i.e.  if  probe()  returns  false),  this  method 
returns  nul 1 . 


©concurrency  (GUARDED) 

V 


public  synchronized  Message  currentO 

{ 

if  (probe()) 

{ 

return  (Message)  messageLi st . get (0) ; 

} 

el  se 
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{ 

return  nul 1  ; 

} 


} 


/* 


* 


Advances  this  Inbox’s  message  pointer, 
©concurrency  (GUARDED) 

V 


public  synchronized  void  advance() 

{ 

if  (messageLi st . size()  >  0) 

{ 

messageLi st . remove(O) ; 

} 

el  se 

{ 

messagePoi nter  =  messagePoi nter  +  1; 

} 

} 

} 


A.6  Message 

Message  is  the  class  that  encapsulates  a  Dynamic  UNITY  message.  It  includes  methods  that 
allow  Dynamic  UNITY  programs  to  retrieve  a  reference  to  the  sender  of  a  message,  and  to 
retrieve  the  contents  of  the  message  (as  a  Serializable).  The  implementation  also  includes  a 
timestamp,  to  enable  the  simulation  of  asynchronous  message  delivery  within  a  single  virtual 
machine. 

Class  A.6  ( Message ,  part  of  a  Dynamic  UNITY  runtime  framework) 
package  dynami cuni ty ; 
import  java.io. Serializable; 

public  class  Message  implements  Serializable,  Comparable 

{ 

//  Instance  Variables 

/** 

*  The  Process  that  sent  this  message. 

**/ 


private  Process  process; 
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/** 

*  The  contents  of  this  message. 

**/ 

private  Serializable  message; 


/** 

*  The  timestamp  of  this  message. 

**/ 

private  long  timestamp; 


//  Constructor 


Constructs  a  new  Message  with  the  specified  sending  process,  message 
contents  and  timestamp. 


Oparam  process  The  sending  process, 
©param  message  The  message  contents, 
©param  timestamp  The  timestamp. 

V 


public  MessageCProcess  process,  Serializable  message,  long  timestamp) 

{ 

this. process  =  process; 
this. message  =  message; 
thi s . ti mestamp  =  timestamp; 

} 


//  Inherited  Instance  Methods 


Compares  this  object  with  the  specified  object  for  order.  Messages  are 
ordered  strictly  according  to  their  timestamps  (their  sending 
processes  and  contents  are  not  used  for  ordering). 

©param  object  The  other  object. 


©exception  Cl assCastExcepti on  if  the  specified  object  cannot  be 
compared  to  this  object. 

V 


public  int  compareTo(Object  object) 

{ 

Message  otherMessage  =  (Message)  object; 


if  ((timestamp  -  otherMessage . timestamp)  <  0) 
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{ 

return  -1; 

} 

else  if  (timestamp  ==  otherMessage . timestamp) 

{ 

return  0; 

} 

el  se 

{ 

return  1; 

} 

} 


//  Instance  Methods 


/** 

*  ©return  the  Process  object  identifying  the  sender  of  this  Message. 

**/ 

public  Process  processO 

{ 

return  process; 

} 


/** 

*  ©return  the  contents  of  this  Message. 

**/ 

public  Serializable  messageO 

{ 

return  message; 

} 


/** 

*  ©return  the  timestamp  of  this  Message. 

**/ 

long  timestampO 

{ 

return  timestamp; 

} 


A.  7  Multiset 
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Multiset  is  the  class  that  implements  the  Dynamic  UNITY  multiset  data  type.  It  uses  the  stan¬ 
dard  Java  Collections  class  HashMap  to  store  a  mapping  from  each  element  of  the  multiset  to 
the  number  of  instances  of  that  element  in  the  multiset. 

Class  A.7  ( Multiset ,  part  of  a  Dynamic  UNITY  runtime  framework) 

package  dynami cuni ty ; 

import  java.io. Serializable; 
import  java. util .HashMap; 

public  class  Multiset  implements  Serializable 

{ 

//  Instance  Variables 

/** 

*  A  HashMap  containing  the  data  members  of  this  Multiset.  The  keys 

*  are  the  data  members,  and  the  values  are  the  number  of  occurrences 

*  of  each  in  the  Multiset. 

**/ 

private  HashMap  setMap  =  new  HashMapQ; 


/** 

*  The  size  of  the  Multiset.  This  is  cached  for  performance  reasons. 

**/ 

private  int  size  =  0; 


//  No  Constructor 
//  Instance  Methods 


/* 


* 


Adds  the  specified  element  to  the  Multiset, 
©param  element  The  element  to  add. 
©concurrency  (GUARDED) 

V 


public  synchronized  void  add(0bject  element) 

{ 

Integer  numberlnSet  =  (Integer)  setMap. get(element) ; 


if  (numberlnSet  ==  null) 
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{ 

setMap . put  Cel ement ,  new  Integer(l)); 

} 

el  se 

{ 

setMap. putCelement,  new  Integer (numberlnSet . i ntVal ue()  +  1)); 

} 

size  =  size  +  1; 


/* 


* 


Removes  one  occurrence  of  the  specified  element  from  the  Multiset 


©param  element  The  element  to  remove. 

©return  true  if  an  element  was  removed  from  the  Multiset, 
false  otherwise. 


©concurrency  (GUARDED) 

*/ 


public  synchronized  boolean  remove(Object  element) 

{ 

Integer  numberlnSet  =  (Integer)  setMap. get(element) ; 

if  (numberlnSet  ==  null) 

{ 

return  false; 

} 

else  if  (numberlnSet . i ntVal ue()  ==  1) 

{ 

setMap. remove(element) ; 
return  true; 

} 

el  se 


{ 

setMap . put(el ement ,  new  Integer (numberlnSet . i ntVal ue()  +  1)); 
return  true; 

} 

} 


/* 


* 


Removes  all 


occurences  of  the  specified  element  from  the  Multiset 


©param  element  The  element  to  remove. 

©return  the  number  of  occurences  removed  from  the  Multiset. 

V 


public  synchronized  int  removeAl 1 (Object  element) 

{ 

Integer  numberlnSet  =  (Integer)  setMap. get(element) ; 
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if  (numberlnSet  ==  null) 

{ 

return  0; 

} 

el  se 

{ 

setMap. remove(element) ; 

size  =  size  -  numberlnSet . i ntVal ue() ; 

return  numberlnSet . i ntVal ue() ; 

} 


/** 

*  ©return  true  if  the  Multiset  contains  the  specified  element, 

*  false  otherwise. 

**/ 

public  boolean  contai ns(0bject  element) 

{ 

return  setMap . contai nsKey(el ement) ; 

} 


/** 

*  ©return  the  number  of  elements  in  the  Multiset. 

**/ 

public  synchronized  int  size() 

{ 

return  size; 

} 


/** 

*  ©return  the  number  of  occurrences  of  the  specified  element  in  the 

*  Multiset. 

**/ 

public  synchronized  int  numberOf (Object  element) 

{ 

Integer  numberlnSet  =  (Integer)  setMap. get(element) ; 

if  (numberlnSet  ==  null) 

{ 

return  0; 

} 

el  se 

{ 

return  numberlnSet . i ntVal ue() ; 

} 

} 

} 
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Appendix  B 

Java  Implementation  of  the  Mutual 
Exclusion  Example 


The  following  Java  classes  implement  a  translation  of  the  mutual  exclusion  example  from  Chap¬ 
ter  5: 


B.l  The  Resource  Program 


The  Resource  program  contains  only  fair,  unquantified  transitions.  Therefore,  it  is  reasonable 
to  implement  it  using  a  simple  round-robin  scheduling  approach. 

Class  B.i  (A  translation  of  the  Resource  program) 

package  dynami cuni ty . srme ; 

import  dynami cuni ty . Inbox ; 
import  dynami cuni ty . Mul ti set ; 
import  dynami cunity. Process ; 
import  dynami cunity. Program; 

public  class  Resource  extends  Program 

{ 

//  Instance  Variables 

/** 

*  A  counter  used  for  iterating  through  the  transitions. 

**/ 

private  int  transi tionCounter ; 


//  Dynamic  UNITY  Variables 


/ 


* 


The  "requestin'1  inbox. 

*/ 
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protected  Inbox  requestln; 


/** 

*  The  "releaseln"  inbox. 

**/ 

protected  Inbox  releaseln; 


/** 

*  A  multiset  that  holds  releases  for  processing. 

**/ 

protected  Multiset  releases; 


/** 

*  The  Process  that  currently  holds  the  Resource. 

**/ 

protected  Process  current; 


//  Constructor 


/* 


* 


Constructs  a  new  Resource  with  the  specified  Process 
Oparam  process  The  process  reference. 

V 


reference . 


public  Resource(Process  process) 

{ 

super (process)  ; 

} 


//  Instance  Methods 

/** 

*  Initializes  the  state  of  the  Dynamic  UNITY  variables. 

**/ 

public  void  initializeO 

{ 

requestln  =  new  Inbox(" requestln")  ; 
releaseln  =  new  Inbox(" rel easeln") ; 


releases  =  new  MultisetO; 
current  =  nul 1  ; 
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transi ti onCounter  =  0; 

} 


/** 

*  Implements  the  fair  transition  set.  This  implementation  executes 

*  the  3  fair  transitions  in  a  round- robin  fashion. 

**/ 

public  void  fai  rTransitionO 

{ 

switch  (transi ti onCounter) 

{ 

case  0: 

{ 

if  ((current  ==  null)  &&  requestln . probe()) 

{ 

current  =  requestln  .  currentO  .  processO  ; 
requestln. advance() ; 
send(current,  "tokenin'1,  null); 

} 

break ; 

} 

case  1: 

{ 

if  ((current  !=  null)  &&  rel eases . contai ns(cur rent)) 

{ 

releases. remove(current) ; 
current  =  nul 1  ; 

} 

break ; 

} 

case  2 : 

{ 

if  (releaseln .  probeO) 

{ 

rel  eases .  add  (rel  easeln  .  currentO  .processO)  ; 
releaseln. advanceO  ; 

} 

} 

} 

transi ti onCounter  =  (transi tionCounter  +  1)  %  3; 

} 

} 
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B.2  The  Client  Program 

The  Client  program  contains  both  fair  and  unfair  transitions.  While  an  implementation  which 
simply  omits  the  unfair  transitions  would  be  correct,  it  would  not  be  interesting  because  it 
would  never  request  the  use  of  the  resource.  We  therefore  want  to  ensure  that  the  unfair 
transitions  at  least  have  a  chance  to  run.  Moreover,  we  want  to  ensure  that  the  client  holds  on 
to  the  resource  for  a  variable  amount  of  time,  rather  than  instantly  sending  it  back  due  to  round- 
robin  scheduling  of  its  fair  transitions.  To  accomplish  this,  we  introduce  some  randomness  to 
the  scheduling  of  transitions.  Unfair  transitions  are  scheduled  randomly  (amongst  themselves), 
with  an  unfair  transition  being  selected  with  increasing  probability  after  a  random  amount  of 
time  has  passed  since  the  last  unfair  transition  was  selected.  There  are  only  two  fair  transitions, 
so  we  repeatedly  select  one  a  random  number  of  times,  and  then  repeatedly  select  the  other 
a  random  number  of  times,  and  repeat  this  cycle.  Of  course,  unfair  transitions  can  execute  in 
between  the  repeated  fair  transitions. 

Class  b.2  (A  translation  of  the  Client  program) 

package  dynami cuni ty . srme ; 

import  java.io. Serializable; 
import  java. uti 1 . Random ; 

import  dynami cuni ty. Inbox; 
import  dynami cunity. Process ; 
import  dynami cunity. Program; 

public  class  Client  extends  Program 

{ 

//  Instance  Variables 

/** 

*  The  time,  in  milliseconds  past  the  epoch,  at  which  the  Client  will 

*  release  the  token  if  it  currently  holds  one. 

**/ 

private  long  fai rTransi ti onSwi tchTime ; 


/** 

*  The  time,  in  milliseconds  past  the  epoch,  before  which  the  Client 

*  will  not  execute  an  unfair  transition. 

**/ 


private  long  unfai rTransi tionThreshol dTi me ; 
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/** 

*  The  random  number  generator  used  to  select  unfair  transitions. 

**/ 

Random  random; 


//  Dynamic  UNITY  Variables 

/** 

*  The  Resource  process  with  which  this  Client  communicates. 

**/ 

protected  final  Process  resource; 


/** 

*  A  flag  indicating  that  this  Client  is  idle. 

**/ 

protected  boolean  idle; 


/** 

*  A  flag  indicating  that  this  Client  is  waiting. 

**/ 

protected  boolean  waiting; 


/** 

*  A  flag  indicating  that  this  Client  is  busy. 

**/ 

protected  boolean  busy; 


/** 

*  The  "tokenin'1  inbox. 

**/ 

protected  Inbox  tokenln; 


//  Constructor 


Constructs  a  new  Client  with  the  specified  Process  reference  and 
initialization  parameters. 


Oparam  process  The  process  reference. 
Oparam  parameters  The  parameters. 

*/ 
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public  Client(Process  process,  Seri al i zabl e []  parameters) 

{ 

super (process) ; 

//  store  parameters 

resource  =  (Process)  parameters [0] ; 

} 


//  Instance  Methods 

/** 

*  Initializes  the  state  of  the  Dynamic  UNITY  variables. 

**/ 

public  void  initialize() 

{ 

tokenln  =  new  Inbox("tokenIn") ; 

idle  =  true; 
waiting  =  false; 
busy  =  false; 

random  =  new  RandomO; 
fai rTransi ti onSwi tchTime  = 

System . cur rentTimeMi 1 1 i s ()  +  1000  +  random . nextlnt(1190000) ; 
unfai rTransi tionNumber  =  0; 
unfai rTransitionThresholdTime  = 

System . cur rentTimeMi 1 1 i s ()  +  random. nextlnt(60000) ; 


/** 

*  Implements  the  fair  transition  set.  This  implementation  uses  a  time 

*  threshold  to  determine  when  to  execute  each  transition. 

**/ 

public  void  fai rTransi ti on () 

{ 

if  (System . currentTi meMi 1 1 i s()  <  fai rTransi tionSwi tchTime) 

{ 

//  transition  0 

if  (waiting  &&  tokenln . probeO) 

{ 

waiting  =  false; 
busy  =  true; 
tokenln . advance() ; 

System . out . pri ntl n(getProcess()  +  "  received  token,  now  busy"); 
//  keep  the  token  at  least  one  second,  and  at  most  2  minutes 


175 


fai  rTransi ti onSwi tchTi me  = 

System . currentTi meMi 1 1 i s ()  +  1000  +  random . nextlnt(119000) ; 

} 

} 

el  se 

{ 

//  transition  1 

if  (busy) 

{ 

busy  =  false; 
idle  =  true; 

send(resource ,  "releaseln",  null); 

System . out . pri ntl n(getProcess()  +  "  sent  token,  now  idle"); 

} 

fai rTransi ti onSwi tchTi me  = 

System . currentTimeMi 1 1 i s()  +  random . nextlnt(60000) ; 

} 

} 


/** 

*  Implements  the  unfair  transition  set.  This  implementation  randomly 

*  selects  an  unfair  transition. 

**/ 

public  void  unfai rTransi ti on () 

{ 

int  unfai rTransi tionNumber  =  random . nextlnt(4) ; 

swi tch  (unfai rT ransi ti onNumber) 

{ 

case  0: 

{ 

if  (idle) 

{ 

idle  =  false; 
waiting  =  true; 

send(resource ,  "requestin'',  null); 

System . out . pri ntl n(getProcess()  +  "  sent  request,  now  waiting"); 

} 

break ; 

} 

case  1: 

{ 

if  (idle) 

{ 

idle  =  false; 

System . out . pri ntl n(getProcess()  +  "  leaving  system  from  idle"); 
stop() ; 

} 
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break ; 

} 

case  2: 

{ 

if  (waiting) 

{ 

waiting  =  false; 

send(resource ,  "releaseln",  null); 

System . out . pri ntl n 

(getProcess ()  +  "  leaving  system  from  waiting"); 
stop() ; 

} 

break ; 

} 

case  3: 

{ 

if  (busy) 

{ 

busy  =  false; 

send(resource ,  "releaseln",  null); 

System . out . pri ntl n(getProcess()  +  "  leaving  system  from  busy"); 
stop() ; 

} 

} 

} 

unfai rT  ransi ti onThreshol dTi me  = 

System . cur rentTimeMi 1 1 i s ()  +  random . nextlnt(60000) ; 

} 


/** 

*  Imposes  the  restriction  that  unfair  transitions  can  not  be  executed 

*  more  often  than  once  per  minute. 

**/ 

public  boolean  unfai  rConditionO 

{ 

//  execute  an  unfair  transition  with  a  probability  based  on  the 
//  amount  of  time  by  which  we’ve  exceeded  the  threshold  time; 

//  if  we’re  100  seconds  past  the  threshold  time,  we’ll  execute 
//  an  unfair  transition 

long  currentTime  =  System . currentTi meMi 1 1 i s () ; 

if  (currentTime  <  unfai rTransitionThresholdTime) 

{ 

return  false; 

} 
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long  probability  = 

(currentTime  -  unfai rTransitionThresholdTime)  /  1000; 

if  (probability  >  random . nextlnt(lOO)) 

{ 

return  true; 

} 

el  se 

{ 

return  false; 

} 

} 

} 


B.3  The  Generator  Program 


The  Generator  program  contains  a  single  fair  transition  that  creates  a  new  Client  process.  We 
use  a  randomly  generated  “sleep”  period  between  10  seconds  and  2  minutes  to  simulate  the 
execution  of  skip  transitions  so  that  the  Generator  doesn’t  create  new  Client  processes  too 
rapidly.  We  also  keep  a  parameter  list  consisting  of  a  single  parameter,  the  resource,  as  an 
instance  variable.  This  prevents  us  from  having  to  construct  a  new  1-element  array  every  time 
the  fair  transition  executes. 

Class  B.3  (A  translation  of  the  Generator  program) 

package  dynami cuni ty . srme ; 

import  java.io. Serializable; 
import  java. uti 1 . Random ; 

import  dynami cuni ty. Inbox; 
import  dynami cunity. Process ; 
import  dynami cunity. Program; 

public  class  Generator  extends  Program 

{ 

//  Instance  Variables 

/** 

*  The  random  number  generator  used  for  determining  the  sleep 

*  period  between  transitions. 

**/ 

Random  random; 

/** 

*  The  initialization  parameters  to  be  passed  to  Clients  created 

*  by  this  Generator. 

**/ 
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Seri al i zabl e []  parameter  =  new  Seri al i zabl e [1] ; 


//  Dynamic  UNITY  Variables 

/** 

*  The  Resource  process  created  by  this  Generator. 

**/ 

protected  Process  resource; 


//  Constructor 

/** 

*  Constructs  a  new  Generator  with  the  specified  Process  reference. 

**/ 

public  Generator (Process  process) 

{ 

super (process) ; 

} 


//  Instance  Methods 

/** 

*  Initializes  the  state  of  the  Dynamic  UNITY  variables. 

**/ 

public  void  initializeO 

{ 

resource  =  Process . i nstanti ate("dynami cuni ty . srme . Resource") ; 
parameter[0]  =  resource; 
random  =  new  RandomO; 

} 


/** 

*  Implements  the  fair  transition  set.  This  implementation  repeatedly 

*  executes  a  fair  transition  and  then  sleeps  for  a  random  period 

*  of  time. 

**/ 

public  void  fai rTransition() 

{ 

Process . i nstanti ate("dynami cuni ty . srme . Cl i ent" ,  parameter) ; 

try 

{ 

Thread . si eep(10000  +  random. nextlnt(50000)) ; 

} 
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catch  (Inter ruptedException  e) 

{ 

} 

} 

} 


B.4  The  System 

The  system’s  initial  program  is  the  Generator  program.  Therefore,  the  system  is  translated  as 
follows: 

Class  B.4  (A  translation  of  the  SingleResourceMutualExclusion  system) 
package  dynami cuni ty . srme ; 
import  dynami cuni ty. System ; 

public  class  SingleResourceMutualExclusion  extends  System 

{ 

//  Constructor 

/** 

*  Constructs  a  SingleResourceMutualExclusion  system. 

**/ 

publ i c  Si ngleResourceMutual Excl usi on() 

{ 

super ("Generator" ,  null); 

} 


//  main()  method 

/** 

*  The  main()  method  for  SingleResourceMutualExclusion,  instantiates 

*  a  SingleResourceMutualExclusion  system. 

**/ 

public  static  void  mai n(Stri ng []  argv) 

{ 

SingleResourceMutualExclusion  srme  = 
new  Si ngl eResourceMutual Excl usion() ; 

} 


} 
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